Coder Legion - Recent posts tagged learning

My AI Coding Project Files: What You Can Borrow

Thu, 22 Oct 2026 18:01:20 +0000

A practical companion to my learning-in-public article about building EthoPipe.

I made these files because I kept getting lost between ideas, generated code, unfinished tasks, and new conversations. They were not a system I designed perfectly at the beginning. They grew as I worked out what would make the next session easier.

This guide shows what each part does and what you might borrow. You do not need all of it, and you do not need my project’s limits. Start with one problem you want to make easier.

You can explore the EthoPipe repository. The file names below come from the working collection behind the article; older copies and local agent instructions may differ from what is currently public.

1. Pick the problem—not the whole setup

The agent keeps adding too much: start with solo-maintainer.md.
Ideas become code before you decide what you want: try idea-to-code.md.
You forget where you stopped: borrow the structure in project-state.md.
Every new conversation needs the same explanation: look at agent-handoff.md.
You want to understand a completed task: use walkthrough-and-tasks.md.
You want a longer record of decisions: start a journal like JOURNEY.md.

For me, rules carry the project’s boundaries, procedures describe a recurring task, and scripts handle repetitive work. A plain note can be useful before you automate anything.

2. Project rules: what should the agent leave alone?

My files: solo-maintainer.md, solo-maintainer-audit.md, and AGENTS.MD.

My solo-maintainer rules keep EthoPipe within what I can follow and maintain. They include a Python-focused application, a direct-dependency budget, and limits on unnecessary infrastructure. Those are choices for my project, not requirements for yours.

Here is a starter template to adapt, not a verbatim copy of my rule:

Project: [What I am building]
Stack: [Languages and tools I have chosen]

Before adding a dependency:
Explain why the existing tools are not enough.

Before changing the architecture:
Describe the change and ask whether it belongs to this task.

Leave unrelated files and unfinished ideas alone.
If instructions conflict, ask instead of guessing.

I can change these boundaries when I choose another direction. They guide the agent’s actions without turning my current setup into a limit on what I can imagine.

3. A task procedure: what am I asking for now?

My files: idea-to-code.md, walkthrough-and-tasks.md, and manage_ideas.py.

My idea-to-code procedure slows me down between brainstorming and implementation. I want to know why the task matters, what can change, and what result I am looking for. I also ask for a short walkthrough afterward so I can follow what happened.

This adapted template is enough to start:

Objective: [One change I want]
Allowed files: [Existing files involved, including tests]
Leave alone: [Dependencies, configuration, unrelated features]

Before editing:
Read the relevant files and explain the plan.

Check:
[What should happen, and how to try or test it]

If the task needs to grow:
Tell me before making unrelated changes.

When finished:
Summarize changes, checks, blockers, and the next action.

I use numbered idea cards and an idea board when I have more to track. You can begin with a checklist in one file. A checked box is a reminder of work, not a replacement for looking at the result.

4. A checkpoint: where did I stop?

My files: project-state.md, PROJECT_STATE.md, and manage_project_state.py.

This is the part I would most happily recommend to someone who keeps reopening a project and wondering what happened last time. Before finishing, leave a note precise enough for your future self.

Current focus: [The task I am working on]

Completed:
[What changed this session]

Still in progress:
[The file, function, question, or failing check]

Next action:
[One concrete thing to do when I return]

Watch out for:
[Uncommitted changes, blockers, or assumptions]

My script writes an active state file and dated copies, but the format is useful without a script. “Keep working on the API” is less useful to me than “open this test and check this failing case.”

5. A handoff: what does a new session need?

My files: agent-handoff.md, generate_agent_handoff.py, and compile_snapshot.py.

A handoff is a checkpoint with enough context for another conversation. My generator collects Git information and can run tests and refresh a snapshot when requested. The snapshot groups selected files; it is not automatically every file in the repository.

Project context: [What I am building and its current boundaries]
Immediate objective: [The next task]
Relevant files: [Only the context needed for this task]
Recent changes: [What the previous session changed]
Checks: [Observed results, or explicitly not run]
Blockers: [What remains unclear]
Next action: [Where to begin]

Fresh conversations help me avoid mixing several tasks. The handoff helps me keep the continuity I actually need.

6. A journal: why did I make that choice?

My files: JOURNEY.md, manage_journey.py, and CHANGELOG.md.

The checkpoint says where to resume. The journal gives me a longer view: what confused me, what I tried, what changed, and what I learned. A changelog has a different job—summarizing project changes for people using or following it.

Date and task:
Problem I was trying to solve:
What I tried:
What I changed or decided:
What helped, and what did not:
What I want to try next:

I do not need a grand milestone for every entry. A small discovery, an unsuccessful experiment, or a decision not to add something can be worth remembering.

7. The supporting files: useful when you need them

You can add automation later. These are the other parts of my collection, grouped by what they help me do:

Quality checks: code-quality-and-standards.md, audit_maintainer_guardrails.py, verify_open_source_standards.py, OPEN_SOURCE_STANDARDS.md, and OPEN_SOURCE_COMPLIANCE.md.
Release steps: release-governance.md.
Bounded companion tasks: code-companion.md and jules.md.
Environment and session context: sync-node.md and AGENTS.MD.
Finding the documentation: SUMMARY.md and the checkpoint-archive README.md.

The scripts are tied to my repository and environment. Read them before running them, and adapt paths, commands, and assumptions to your own project. You do not have to introduce a script just to use its underlying idea.

8. The older files show how the setup grew

My July material includes implementation_plan.md, walkthrough.md, walkthrough1.md, task-project.md, update.md, github_actions_audit.md, github_actions_audit2.md, technical_audit_report_1.md, technical_audit_report3.md, project_technical_report.md, and agent-handoff-report.md.

The October records include IDEAS_BOARD.md, PROJECT_STATE.md, STATE_20261012_152433.md, SOLO_MAINTAINER_AUDIT_20261012_151845.md, SOLO_MAINTAINER_AUDIT_20261012_160520.md, OPEN_SOURCE_COMPLIANCE.md, and LLM_SNAPSHOT.MD.

For the bigger narrative, I kept JOURNEY.md, CHANGELOG.md, gemini-code-phase.md, gemini-code-telemetry-sync.md, project-timeline.md, and antigravity-system-directive.md. The earlier Adobe Firefly.docx article and comment screenshot are the creative starting point, rather than files to install.

I would browse these for examples rather than copy their historical status into a current project. The July files show individual plans and findings; the October collection shows more repeatable record-keeping. The paperwork grew because I was learning what I needed—not because every project needs that many documents.

9. Adapt the format to your tool

In Antigravity, rules are persistent project instructions, while skills package reusable task procedures. The current documentation explains the supported locations and activation behavior. My older workflow files can supply the content, but their old packaging may need changing.

If you use another tool, look for its project-instruction and reusable-task features. Ask for help adapting the content, then check the documentation and try a small task. A file is useful only if the tool actually finds it.

10. Leave room for experiments

You might ask for a few approaches without authorizing edits, try one in a separate experiment, and write down what you learned. That can be worthwhile even when nothing gets merged or published.

These files are meant to make exploration easier—not turn learning into another set of hurdles. Keep what helps. Change what does not. Your project can be a place to play.

AI assistance: I used Gemini and Microsoft Copilot to discuss, organize, and edit this guide. The project files and experience are mine.

I’m Still Learning AI Coding: The Rules and Workflows Helping Me Find My Way

Tue, 20 Oct 2026 19:22:32 +0000

What building EthoPipe is teaching me about AI tools, project rules, and leaving room to experiment

Update: I've linked the companion guide :)

After my post How Adobe Firefly and Copilot Taught Me to Prompt for Code (Part 1), a reader asked whether smaller coding prompts worked better than one detailed prompt. I answered yes, but the question stayed with me. What did “smaller tasks” actually look like in my project—and where did rules and workflows fit?

I am not an expert in AI-assisted development. I am learning by building something I care about. These are the files and habits helping me find my way. You might borrow one part, change another, and ignore the rest.

I used to be strongly against AI. I refused to use it. Now I am writing about how I work with it—not because I suddenly have everything figured out, but because I changed my mind and started experimenting.

My project is EthoPipe, an open-science Python project for canine ethology. At one point, I restarted because I was getting lost among ideas, generated code, instructions, and unfinished tasks. I wanted the tools to help me follow the project, not produce more work I could no longer understand.

My Firefly experiments gave me a useful starting point. A short image prompt could work because the reference photo and settings carried part of the instruction. With coding, I began asking the same practical question: what does the agent need to know before I ask it to change something?

1. Decide what I want before asking the agent to build it

I usually brainstorm in the Gemini app, then move to a coding agent when the direction is clearer. Sometimes I use Copilot for another perspective or when I feel stuck. An IDE agent can discuss ideas too; separating the conversations simply helps me avoid turning every possibility into a feature.

An idea can stay an idea. Before moving to code, I ask: What am I changing? Which files belong to the task? What should stay untouched? How will I know it worked?

What changed between July and October

My July files already contain plans, audits, and walkthroughs. They helped me notice problems such as a filename mismatch and checks that were configured but not working. I was learning to pay attention to the work around the code, not just the code itself.

By October, I had an idea board, more specific project rules, scripts for recording stopping points, and a handoff process. I did not design that system in advance. I kept adding or adapting a file when the same confusion came back.

These files make the next session easier. Some guide the agent, some automate repetitive work, and some remind me where I left off.

2. My rules guide the agent—not my imagination

When I moved my instructions from Gemini Code Assist to Antigravity, some did not work the way I expected. I had to redo parts of the setup. That was frustrating, but it also made me pay more attention to where the files belonged and how the tool used them.

The distinction that helps me is simple: rules describe the project’s boundaries; workflows describe how I approach a recurring task; scripts handle repetitive checks or record-keeping. Each has a different job.

The packaging changes too. Antigravity now documents skills for reusable task procedures and rules for persistent instructions. I still call the overall process my workflow. If you borrow my files, check the current documentation for your tool rather than assuming the old folder structure will work unchanged.

I still review what the agent changes. “Do not touch this” is a useful instruction, not a reason to stop paying attention.

One example: keeping the project small enough for me

I do not want the agent adding a setup I cannot understand or maintain. My solo-maintainer rules limit dependencies, extra languages, and unnecessary infrastructure. Those boundaries fit EthoPipe, and I can revise them when the project needs something different.

A few lines from my solo-maintainer.md file:

- Direct runtime dependencies in pyproject.toml are capped at <= 8 packages.
- Always prefer Python's standard library
  (pathlib, tomllib, dataclasses, argparse, typing, sqlite3)
  over adding third-party packages.
- Keep EthoPipe as a single modular Python service
  (FastAPI + Supabase).
- Individual files must remain under 600 lines.

Your version might need a frontend framework, another database, or more dependencies. The useful part is deciding what fits your project and writing it down, rather than explaining it again in every conversation.

The constraints guide the AI’s actions, not my imagination. I can explore another direction without authorizing new packages, rewritten files, or unrequested features. Not every possibility needs to become code.

3. Give a smaller task a clear purpose

My idea-to-code file follows triage → specification → test first → minimal implementation → QA and journal. That may sound formal, but it helps me pause long enough to decide what I need before files start changing.

Instead of “improve my project,” I ask for one change and name the files involved—including tests. If the agent finds a larger issue, I want it to tell me rather than quietly turn the task into something else.

Here is an example of how I would describe a small task:

Objective:
Check the subject_id length boundary.

Allowed files:
src/pipeline/models.py
tests/test_models.py

Non-goals:
No dependency, CI, or unrelated refactoring changes.

Acceptance:
255 characters accepted; 256 rejected.

Process:
Inspect existing tests. Add a regression test only if missing.
Make the smallest necessary change. Run targeted and full checks.

Stop:
Ask if requirements conflict or the boundary is undocumented.

Closeout:
Changed files, commands and results, blockers, next action.

The prompt is not especially short; it is specific. In this example, the limit and tests already exist in my snapshot, so inspection comes before generating anything new.

That is why my answer is not “always write short prompts.” A longer discussion can establish the direction; smaller tasks carry it forward. The rules provide project context, and the task says what I want now.

4. Leave myself a way to come back

I often open a new conversation for a particular task. It keeps unrelated ideas out of the way, but I do not want to explain the whole project again. My state and handoff files help bridge those sessions.

The state file records what I was doing, where I stopped, and what comes next. A handoff adds relevant project changes and checks when requested. Neither me nor the agent has to remember every detail of the previous conversation.

The kind of note that helps me resume

From my October 12 PROJECT_STATE.md checkpoint:

Where We Stopped:
Completed project-state skill, workflow, CLI engine
(scripts/manage_project_state.py), and state.ps1 helper
with docs/states/ historical archiving.

Quick-Resume Action:
Proceed to localized storage adapter design for Kimball
Star Schema persistence or review project state via
.\scripts\state.ps1.

The note is ordinary—and that is why it helps. I can return to it and know where to start. One checkpoint recorded the state tooling in progress; the next gave me a new task. The files keep that thread intact.

5. Ask for help, read the docs, and keep adjusting

When I do not know how to write a rule or workflow, I ask Gemini to help. I explain what I want, work through a draft, compare it with the documentation, and try it. If I cannot describe the goal, that is a sign I need to explore the idea a little longer.

I work with the agent, review changes, and ask for a walkthrough when we finish. I want to understand what happened and what comes next. The goal is not to pretend I could have written every line unaided; it is to learn enough to keep working on my project.

Google’s learning resources—including GEAR and courses available through my student benefits and learning credits—helped me understand the tools. The documentation also helped explain why instructions from one environment needed adapting in another.

6. Coding experience helps—but the tool still needs learning

I come from outside the usual developer path. I cannot speak for someone with twenty years of coding experience, but I can offer a beginner’s perspective: I am still asking questions about how these tools work.

Coding experience and familiarity with a coding agent are related, but not identical. Recognizing a bad abstraction or debugging a problem is valuable. Learning how a particular agent reads instructions, carries context, asks for approval, and handles a task is another skill. Experience gives you something to build on; it does not remove the need to learn the tool.

I wonder whether the familiar setting makes that easy to overlook. It is still an editor, a terminal, and a repository, but some of the interaction now happens through conversation. Reading a tutorial or asking how a feature works does not diminish anyone’s experience.

I would start with an ordinary task: explain an unfamiliar function, suggest a test, or make a change I can follow. Then I can inspect the result and adjust my instructions. That gives me room to learn without expecting the first prompt to solve everything.

Having once refused to use AI, I am reluctant to insist that anyone must embrace it. But curiosity is enough reason to try. A question or mistake does not have to become a verdict on you—or on the technology.

I do not think you need the most expensive tool to begin

Some articles leave me with the impression that useful AI-assisted coding requires the newest model or most expensive subscription. My experience makes me question that. I think an accessible tool can produce decent work when it fits the project and you take time to learn it.

I started with the access I had. Gemini became familiar, and search fits the way I research. An upgrade might help with a specific limitation, but I do not want a price tag to make someone feel they cannot begin. Learning to describe the task has mattered more to me than chasing the model everyone is discussing that week.

7. Experimentation is a reason to build—not a consolation prize

A personal project can be a place to play

I do not know whether EthoPipe will become something bigger. It already gives me a reason to learn, make mistakes, ask questions, and try ideas. That is not a consolation prize if it never becomes a finished product. It is a reason to build.

A personal project does not have to become a company, a polished product, or proof that you are a “real” developer. You can vibe code, run tests, discard an experiment, and start again. AI can help you be more creative, not just more productive.

I can ask for three approaches without authorizing file changes, choose one, and try it separately. I can ask the agent to explain the result—or discard it if it does not help. Exploring possibilities is different from adding all of them to the main project.

The agent needs a clear job; my ideas need room. I can change the rules, explore another direction, or leave an experiment unfinished. The boundaries help me follow the work, not postpone it.

If you want to try this, start with one file

Pick a task you keep repeating or a problem that keeps confusing you.
Write a small rule or procedure in your own words.
Ask your AI tool to help clarify it, then check how your environment loads it.
Try it on one manageable task and look at the result.
Keep what helps, change what does not, and leave yourself a next step.

You do not need my full collection. I am sharing it because concrete examples would have helped me understand what people meant by rules and workflows. Take what solves a problem for you, then adapt the stack, limits, and language.

Smaller tasks help me, but I am not trying to make my ideas smaller. I am giving the agent a clearer job while I keep learning and experimenting. The prompt says what to do now. What I imagine next is still up to me.

What have you tried with AI simply to learn or explore? I would love to hear about the experiments—not just the finished products.

AI assistance: I used Gemini and Microsoft Copilot to brainstorm, organize, and edit this article. The experience and project files are mine.

My files: the companion guide, “My AI Coding Project Files: What You Can Borrow,” groups the rules, workflows, scripts, and records behind these examples so you can choose one useful starting point.

How Adobe Firefly and Copilot Taught Me to Prompt for Code (Part 1)

Sun, 18 Oct 2026 17:06:01 +0000

Every time the topic of AI comes up in developer spaces, the conversation usually splits into two extremes: people who claim AI takes "zero effort" because you just type a sentence and get a finished product, and people who dismiss prompting as a soft, non-technical skill that has nothing to do with "real" engineering.

Anyone who has actually spent hours trying to force a foundation model to produce a specific, non-generic output knows that both takes are wrong.

My goal wasn't to generate random fantasy landscapes or stock avatars. I wanted to recreate my dog—an American Pit Bull Terrier (APBT)—across distinct visual styles so I could design a clean, accurate brand logo. To do that, I set two strict rules for myself:

1. Only Native Firefly: I refused to jump to third-party models when things got difficult; I committed exclusively to the native Adobe Firefly model (working through Firefly Image 3 and 4, long before conversational in-canvas editing existed).

2. Only My Own Photos: I never used stock presets or random internet pictures. Every single generation was fed exclusively with my own photographs of my dog.

That self-imposed constraint turned into a masterclass in fighting statistical bias, understanding parameter pipelines, and sanitizing noisy inputs. Looking back, the exact workflow I had to build to get Firefly to respect canine anatomy is the same mental model required to get an LLM to write production-ready code.

(Note: This is the first part of a multi-part series exploring how creative AI workflows translate directly into software engineering and systems architecture.)

my dog for reference

Behance Project: Morgan "Vega"

Fighting the "Default Weight" (Why Lazy Prompts Fail)

When I started experimenting with Firefly in 2024 and locked into a heavy daily workflow in 2025, I quickly hit a wall. If you type "pitbull" into an image model by itself, you do not get an accurate American Pit Bull Terrier.

Because public stock datasets suffer from massive tag pollution—where people tag Mastiff crosses, Cane Corsos, American Bullies, and random block-headed mixes under the same umbrella term—the model’s latent space defaults to two extremes: either an exaggerated, short-legged caricature or a generic Labrador-mastiff hybrid with mushy features.

Because I refused to switch to another generator, I had to learn how to override Firefly's statistical baseline using my own reference photos, active human feedback (RLHF), and structured parameter control.

The Engineering Parallel:

LLMs do the exact same thing with code. If you give a coding model a lazy prompt like "build an API endpoint to process user data," its weights will pull straight toward the internet's most common, bloated, and outdated tutorials. To override the statistical default, you cannot rely on umbrella terms. You have to provide a structural blueprint and specify exact boundaries.

How Firefly Actually Works: Parameter Pipelines & Edge Copilot

Most people who haven't used Adobe Firefly assume it works like a simple chat box. In reality, Firefly’s interface is a structured parameter pipeline that separates geometry, style, and text tokens into distinct control layers.

Instead of relying on a single text prompt to do everything, Firefly breaks generation down into specific modules:

General & Content Settings: Choosing the base model (Firefly Image 3 / 4), locking the Aspect ratio, switching Content type between Photo and Art, and dialing the Visual intensity slider.
Composition Reference (Structure): This is where I uploaded my own photos of my dog. Under the hood, Firefly uses this slot for edge detection and depth mapping, forcing the new generation to follow the physical geometry of the uploaded photo.
Style Reference & Effects Taxonomy: Rather than guessing random adjectives, Firefly categorizes visual weights into structured buckets—Movements, Themes, Techniques, Effects, Materials, and Concepts (such as Minimalism, Flat design, Anime, or Doodle drawing), alongside explicit dropdowns for Color and tone, Lighting, and Camera angle.

To master this setup, I realized I needed to understand what all those art movements and techniques actually meant, and how Firefly's text parser expected them to be combined with my reference uploads.

I opened Copilot in the Edge browser and used it as my domain tutor and syntax compiler:

Learning the Art Taxonomy: I used Copilot to learn the technical differences between the styles available in Firefly—what separates a digital painting from continuous-contour linework, cross-hatched doodle styles, manga ink, or flat vector color blocking.
Compiling Firefly-Specific Prompts: Firefly didn't want chatty paragraphs; it wanted clean, comma-separated tokens that complemented the sidebar parameters. When the model kept cropping or distorting lower limbs, I used Copilot to help refine explicit anatomical and positional tokens (like standing and showing his legs) that worked with my uploaded Composition Reference.

Adobe Gallery

(an American Pit Bull Terrier, black, standing, in a simple background, digital painting)

One of my early experiments feeding my dog's photo into this pipeline was hand-picked by Adobe to be featured in the official Adobe Firefly Gallery.

If you look at the prompt on that featured gallery card—an American Pit Bull Terrier, black, standing, in a simple background, digital painting—a casual viewer might assume it took zero effort. What they don't see is how the pipeline worked together: because I fed my own photograph into the Composition Reference slot and gave continuous feedback on anatomically accurate runs, my photo carried the morphological constraints (the exact rose/half-pricked ears, the lean chest, the straight front assembly). That allowed the text prompt to stay surgical and declarative.

The Engineering Parallel:

Prompting complex systems is configuration and technical specification. When your underlying architecture is solid—when your Pydantic schemas, type definitions, and structural interfaces are already passed into the system's parameters—you don't need to write a 500-word conversational essay begging the AI not to hallucinate. Your prompt can be a clean, concise instruction because the structural reference is already doing the heavy lifting.

The Pre-Editing Experiments: Diagnosing Cross-Attention Bleed

Even with Firefly's Composition Reference locking my dog's anatomy in place, pushing my raw photos across radically different art styles before in-canvas editing existed exposed a major flaw in how diffusion models read reference images.

Manga drawing style of an American Pit Bull Terrier, black.

 American Pit Bull Terrier, solid black, doodle style

 American pit bull terrier, solid black, standing and showing his legs, doodle style

American pit bull terrier, solid black, standing and showing his legs, cartoon style

black american pit bull terrier standing

Looking across these early runs—all generated from my own photos—you can see two things happening at once:

What Worked (Morphological Locking): Whether I pushed the engine toward stark white-on-black ink, clean doodle style linework, manga drawing style, or cartoon style pop art, my dog's core anatomy, ear carriage, and muscle tone stayed true to my photos.
Where the Noise Leaked In (Environmental Contamination): Look closely at the backgrounds. Because Firefly's Composition Reference evaluates the entire uploaded image, it couldn't tell where my dog ended and the backyard began. In the manga generation, a metal pole and patio clutter from my original photo bled straight into the illustration. In the walking side-profiles, the model spent half its attention rendering the wooden deck planks and walls. And in the sketch and dark stencil, background shadows confused the style weights into hallucinating fake artist signatures and floating geometric shapes in the negative space.

Input Sanitization: The 1:1 Cutout Breakthrough

Diagnosing why those background artifacts were happening led to my biggest workflow breakthrough: I started completely removing the background from my dog's photos and standardizing the canvas to a 1:1 square before uploading them into Firefly's Composition Reference

Suddenly, every generation locked in without environmental bleed. Why?

Eliminating Cross-Attention Contamination: In a raw outdoor photo, 60% of the pixels are grass, fences, poles, and shadows. The model’s attention layers try to apply your Effects and Styles across all that background noise at once. Stripping the background zeroed out those competing tokens, forcing 100% of the feature extraction onto the dog's silhouette.
Unambiguous Edge Maps: Isolating the subject gave Firefly's Composition Reference algorithm a stark, vector-clean perimeter to color and shade within—instantly eliminating the hallucinated signatures and floating background scribbles.
Native Latent Geometry: Setting the input cutout and Firefly's Aspect ratio parameter to a centered 1:1 square aligned with the native geometry of diffusion grids, eliminating compositional drift and giving me the exact, isolated character assets I needed to composite my final brand logo by hand.

The Engineering Parallel:

Garbage context in, garbage code out. Those metal poles and fake signatures in my early dog drawings are the exact visual equivalent of what happens when a developer dumps an entire cluttered repository, unformatted stack traces, and five unrelated files into an LLM context window and says "my code is a mess, fix it."

The Takeaway (And What's Next in This Series)

For a long time, I fell into the trap of thinking that being "good at prompting" didn't count as a real technical skill. We are conditioned to believe that unless we are suffering through manual boilerplate or memorizing every flag from scratch, we are somehow taking a shortcut.

But refusing to take the easy route—sticking exclusively to the Firefly model, feeding it only my own photography, using Edge Copilot to master art taxonomy and syntax, diagnosing attention bleed across dozens of test runs, and engineering a clean 1:1 preprocessing pipeline—taught me what prompting actually is. Whether you are steering a diffusion model away from tag-polluted training data or directing a coding agent through a production refactor, the core discipline is the same: systems thinking.

Coming up next in this series:

In the next post, I’ll be sharing my full Behance project, where I break down the complete visual archive of my Firefly attempts—showing the direct before-and-after impact of the 1:1 cutout pipeline—and how I took those isolated AI assets into Photoshop to composite and finish the final brand logo. Stay tuned!

List Of Machine Learning (ML) Models

Fri, 16 Oct 2026 12:38:00 +0000

Found this list while training it into my new personal LLM, its a list of machine learning (ML) models, with descriptions and settings. They are fairly easy to use if you are comfortable on the command line, but it's technical enough that it won't sound familiar to most people, so its good reading. If you want the full info, copy below this line into your favorite AI and say "Take this list of ML models, research them and give me a description and use case for each." or tell it what you need to do and ask which one of these will do that. Learning just the 4 types and understanding that you chain multiple ones together with / without an LLM in the process. Warning too, frontier models will not write good training data for these just like all training data, will either flag you or just write generic bad data on purpose, so never ask it to make you training data unless its open source (deepseek, qwen etc).

Ok so main purpose first, 4 categories:

CLASSIFIERS - Take input, predict a category label (a string).
Example: input = "I want to cancel my account", output = "cancellation"

Requires labeled training data: each training row has input + a string label.

Specific Models: KNN (K-Nearest Neighbors), NAIVE BAYES (Gaussian Naive Bayes), DNN (Deep Neural Network / MultilayerPerceptron), RANDOM FOREST, TREE (Classification Tree), ADABOOST (Adaptive Boosting), LOGISTIC REGRESSION

REGRESSORS - Take input, predict a number (a float).
Example: input = [sqft, bedrooms, age], output = 350000.00

Requires labeled training data: each training row has input + a numeric label.

Specific Models: RIDGE (Ridge Regression), KNN REGRESSOR, SVR (Support Vector Regression), MLP REGRESSOR (Neural Network Regressor), GRADIENT BOOST

CLUSTERERS - Take input, assign it to a group (integer cluster ID).
Example: input = [age, income, spend], output = 2 (meaning cluster 2)

No labels needed. The algorithm discovers groups on its own.

Specific Models: KMEANS, DBSCAN, FUZZY C-MEANS

ANOMALY DETECTORS - Take input, flag it as normal (0) or anomaly (1).
Example: input = [transaction_amount, time, location], output = 1 (anomaly)

Train on normal/clean data only. Anything that looks different gets flagged.

Specific Models: ISOLATION FOREST, LOCAL OUTLIER FACTOR, ROBUST Z-SCORE

How Online Learning Can Help Coaching Institutes Go Digital

Fri, 16 Oct 2026 10:04:19 +0000

Today’s students learn very differently than students did even just a few years ago. Although many still prefer sitting in a classroom and learning directly from a teacher, others want the flexibility to study from home, revisit recorded lessons or attend classes without traveling long distances.

Coaching institutes see this change as a challenge and an opportunity. Students have never had so much choice and institutes need to find ways to meet their expectations, without compromising on the quality of teaching.

The transition to digital can help. It enables the coaching centers to reach out to students beyond the immediate neighborhood, offer courses in different formats and make learning resources available when students need them. However, going online is not only about having classes on video call. Institutes also need an easy way to organize courses, share study materials, assess students and keep everything running smoothly.

The right learning platform can make taking your institute online a practical next step rather than a daunting task.

Why Digital Transformation of Coaching Institutes?

Anyone who has run a coaching institute knows there are certain limitations of classroom teaching. The size of an institute is determined by the space, teachers and schedule. It is limited by the number of students it can accommodate. Traveling long distances each day can be hard for students who live far away, and students who miss a class might find it hard to catch up.

Digital learning addresses some of these challenges.

Students can attend online classes, study materials and recorded lectures whenever they want to revise a topic. This is especially useful for competitive exam preparation, where students often need to practice again and again, revisit concepts they find difficult.

The biggest benefit for institutes is the chance to reach more learners without having to set up another physical center. For example, a coaching institute in one city can begin online courses for students in other parts of India.

It also allows for trying out different formats of teaching. Institutes can continue with regular batches in the classroom and also start recorded courses, online revision sessions or extra practice classes.

The idea isn’t to replace classroom teaching. To provide students with more ways to learn and help institutes make better use of their teaching resources.

What Is a Good Online Learning Platform for Institutes?

Online classes are pretty easy to begin with. The complications can come in when the number of students increases, and you’re managing the entire learning experience.

Study materials can be scattered across different apps, assignments can get lost in messages, and teachers can spend too much time on administrative tasks. Students, however, may have a hard time locating the correct lesson or recalling what they need to complete.

A good online learning platform can collect these activities together.

It must be user-friendly. Students should be able to access their courses and learning materials without needing to call for technical assistance all the time. Teachers should be able to create lessons and conduct their classes without having to deal with a system that is overly complex.

Another important aspect is course management. Institutes need an easy way to organize lessons, upload resources and make learning content available to students. Assessments, quizzes and assignments can help to further support the learning process by helping students to practice and giving teachers a better understanding of their progress.

It is also worth considering what the institute will need in the future. A platform that works for a small batch should optimally be able to handle growth as more students enrolll and new courses are added.

When selecting the best online education platform for institutes to go digital, institutes should consider what actually matters to their teachers and students. The best solution is not always the one with the most features. It is the one that helps you to teach, makes learning more accessible and simplifies everyday administration.

How to Create Your Own Branded Online Academy

Imagine students who are aware of your institute’s name, have faith in your faculty, and are eager to learn from you even if they can’t attend your physical classes. An online academy provides you a way to make that happen.

Institutes can create their own digital learning environment rather than using third-party learning platforms. The institute forms its identity outside of the classroom and students can take courses associated with the institute.

For instance, a coaching center for competitive exams could provide recorded foundation courses to students from all over India. An institute of language can start online classes for working professionals who cannot attend regular classes. A training center could offer short courses to learners who want to acquire specific skills.

For institutes, a platform to start their own branded online academy in India can be the first step to this model. Depending on the features it offers it can be a tool for organizing courses, sharing learning materials, managing student access, and delivering educational content online.

Of course, starting an academy is more than just setting up the technology. Institutes need to think about what courses they will offer, who their clients will be and how they will offer a valuable learning experience. Course content should be clear, engaging and appropriate to the needs of the target audience.

It is equally important to consider what happens after a student enrolls. Easy access to lessons, clear instructions, timely communication and appropriate support for learners can make a real difference.

A successful online academy is a natural extension of what an institute already does well. Technology takes care of the teaching there, but the quality of the teaching is what gives the students a reason to stay.

Hybrid Learning: A Viable Option for Coaching Institutes?

Not every institute is prepared to go full online, and many students still enjoy the experience of learning in a classroom. Hybrid learning is the middle ground.

In simple terms, hybrid learning is a mixture of classroom teaching and online classes or digital learning resources. Students can attend regular classes at the institute and revise at home with recorded lectures or study materials online. Institutes may also offer selected sessions online to students who live farther away.

Take an example of a coaching center where some students come to class physically and others can’t travel regularly. By employing a hybrid model the institute can maintain service to both groups without completely reworking its existing instructional model.

Students enjoy greater flexibility, while teachers can tap into digital resources to enrich classroom instruction. Recorded lessons, when available, can be especially useful for students who need to review a difficult concept before an examination.

A platform for hybrid classes in coaching institutes can help to bring these learning activities in a more organized environment. Depending on the platform’s capabilities, institutes may be able to manage live sessions, recorded lessons, study materials and assessments along with their regular teaching activities.

The key is to ensure that online students receive the same amount of attention and clarity as those in the classroom. Timetables should be simple to follow, learning materials accessible and communication between teachers and students consistent.

Hybrid learning, if planned well, helps institutes retain the intimacy of classroom teaching, while giving students the convenience of digital education.

How an Institute Can Grow Through Digital Learning

Growth does not have to mean opening another branch or increasing the number of classroom batches. Sometimes it means finding new ways to transfer the knowledge and teaching expertise that an institute already has.

Digital learning can help make that happen.

An institute may introduce additional courses, provide recorded lessons for revision, or design specialized programs for students with different learning needs. It can also reach learners in locations where it would be difficult or expensive to establish a physical center.

There are practical benefits, as well. If learning materials and course activities are managed through a central platform, teachers can spend less time looking for resources or doing repetitive administrative work. Students find it easier to find the materials they need, and institutes can run their courses more consistently.

In addition, digital learning can assist institutions in adapting to changing student expectations. Some learners like live classes, others prefer recorded lessons and many are helped by a combination of both. An institute can reach a wider audience by providing a variety of learning formats.

But technology is only one part of the story. Institutes still need good teachers, relevant courses, good communication and a true understanding of their students. A digital platform can be of help, but it cannot substitute the trust that is built by quality teaching and a good learning experience.

ItLearn: Making Digital Learning Accessible

ItLearn by Imbibe Technologies is an education technology platform to assist institutions in delivering and managing digital learning. ItLearn offers an opportunity for coaching institutes who wants to go beyond traditional classroom teaching to explore a more structured approach to online education. It can support an institute’s efforts to make learning accessible to students beyond the physical institute and to adapt to evolving expectations around digital education. Institutions considering this transition can reach out to the ItLearn team to learn how the platform’s functionalities cater to their requirements for course delivery, learning materials, and student accessibility. No matter if the goal is to enhance an existing digital learning model or to discover new ways to deliver education, the first step is to determine what the institute needs and how ItLearn can fit into that plan.

Conclusion: Bring Your Institute Outside the Classroom

Going digital needn’t mean giving up on traditional teaching. That means more opportunities for your institution to reach students, to share knowledge, to fit learning more seamlessly into their lives.

Maybe you want to reach students in other cities. Or maybe you want to offer your own online courses. Or maybe you want to combine classroom and digital learning. Whatever your goal, the right platform will make the changeover easier to handle.

First look at the needs of your students and where your existing model of teaching could be more elastic. Then select a solution that supports those needs without unnecessarily complicating everyday teaching.

Perhaps your institute's growth will begin outside the classroom next. Get in touch with ItLearn from Imbibe Technologies today to talk about your digital learning needs and find out how you can take your coaching institute online, reach out to more students and create a future-ready learning experience.

Personal Branding for Developers: Make Your Growth Visible

Wed, 14 Oct 2026 09:11:05 +0000

Learning to code gives us something to build. Sharing what we learn gives people a way to find us.

A project on LinkedIn. A question in a community. A hackathon experience turned into a blog post.

Each offers a glimpse of what we care about, how we think, and where we are heading.

For me, personal branding starts with making that growth visible.

Give people a reason to remember you

"I'm learning to become a developer" is an introduction. Our work adds the details.

A project shows the problem we wanted to solve.
A blog post explains our decisions and discoveries.
A thoughtful contribution shows how we engage with others.

Over time, those details give someone a reason to think:

"They care about this problem. I'd like to work with them."

We can start while we are still learning. Explaining what we tried, where we struggled, and what changed is already worth sharing.

Community shows me where to grow

I have participated in hackathons, and I'm active in other communities.

I love communities because they help me see where I need to grow.

Learning alone can make it difficult to spot the gaps in my understanding. Other people bring questions, approaches, and experiences I might never encounter on my own.

A question I struggle to answer becomes something to explore.
Someone else's approach reveals an option I hadn't considered.
Feedback helps me decide what to work on next.

That is part of what I want to document here: what I did, what I learned, and what I still need to figure out.

Connections travel further than we expect

An online community can become a local meetup. A familiar username can become a teammate.

Sometimes, we find ourselves sharing experiences and encouraging one another in places we never expected.

Relationships grow through small actions:

Remembering someone's project.
Offering useful feedback.
Sharing an opportunity.
Celebrating a small step forward.

Participating means becoming someone who helps others move forward, too.

Why I'm starting Opportunity Map

Writing brings together three things I want to do:

Reflect: understand what I'm learning and where I'm going.
Share: make my experience useful to someone else.
Connect: meet people I could learn, build, or work with.

Through Opportunity Map, I'll share:

Lessons from projects and hackathons.
Experiences and discoveries from communities.
Opportunities to get involved, from internships to volunteering.

I want this series to connect possibilities with practical next steps.

Start with one honest contribution

Share a problem you solved. Explain a decision you made. Write about a question that changed your thinking.

A useful starting point is:

What did I try, what did I learn, and what would I do differently?

I think of what comes next as an ocean of possibilities. I don't know who will read a post or where a conversation might lead.

But sharing my work leaves a coordinate someone else can find.

This is where my Opportunity Map begins.

Learning `just`: A Practical Task Runner

Tue, 13 Oct 2026 12:45:10 +0000

I've been learning just recently.

I came across it while setting up a Python project and looking for a simple way to collect all the commands I use during development.

This started with something I got used to in Elixir.

One of the things I really like about Elixir projects is that you can put the common development tasks behind simple commands/aliases:

mix format
mix test
mix ci

You don't have to remember every command that runs underneath. The project gives you a small set of commands and you use those.

I wanted something similar for a Python project.

For example, instead of remembering all the different checks I need to run, I wanted to be able to do this:

just ci

and let the project take care of the rest.

My first thought was Make

Make was the obvious choice.

I've used Make a lot, and it works. It's installed almost everywhere, most developers have seen a Makefile before, and there is a huge amount of existing knowledge around it.

So I started there.

The setup was pretty small:

format:
	uv run ruff format --check .

lint:
	uv run ruff check .

typecheck:
	uv run mypy src/

test:
	uv run pytest --cov=src --cov-report=term-missing

ci: format lint typecheck test

That gave me exactly what I wanted.

I could run:

make format
make lint
make typecheck
make test
make ci

Nothing complicated.

But while doing this, I kept seeing just mentioned in newer projects.

That made me curious.

Not because I thought Make was bad. I still use it a lot, and I have no problem reaching for it.

I just wondered what just was doing differently.

Was it basically Make with different syntax? Was it easier to use? Did it solve some of the small annoyances that come with Make?

So I decided to rebuild the same thing in just and see.

The `just` version

The nice thing was that I didn't have to change any of the actual commands.

I just changed the wrapper around them:

format:
    uv run ruff format --check .

lint:
    uv run ruff check .

typecheck:
    uv run mypy src/

test:
    uv run pytest --cov=src --cov-report=term-missing

ci: format lint typecheck test

That's pretty much the whole file.

Now I can run:

just format
just lint
just typecheck
just test

Or everything with:

just ci

The ci recipe depends on the other four recipes, so just ci runs them in order and stops when one fails.

For what I was trying to do, it felt very familiar.

And that was probably the first thing I noticed. I didn't really have to learn a new way of thinking about the problem.

A few things I liked about `just`

The basic syntax is very similar to Make.

You have a recipe, optional dependencies, and then the commands to run:

recipe_name: dependency1 dependency2
    command to run

But there are a few differences that make sense when you're using it mainly as a task runner.

No `.PHONY`

With Make, you often have something like:

.PHONY: format lint typecheck test ci

That's because Make is also a build system and cares about files and timestamps.

For these development commands, I don't really need that behaviour.

just doesn't use file timestamps to decide whether a recipe needs to run, so there is no .PHONY declaration to maintain.

No tab problem

Then there is the classic Make issue where a command needs to be indented with a tab.

I've definitely lost time to that one.

With just, you don't have that same tab requirement. You use normal indentation.

It might seem like a small thing, but I like small improvements in tools I use.

`just --list`

This was another nice surprise.

You can run:

just --list

and get a list of the recipes available in the project.

You can add comments above recipes too:

# Format check
format:
    uv run ruff format --check .

# Run tests
test:
    uv run pytest --cov=src --cov-report=term-missing

Those comments can then show up when listing the recipes.

You can also make just itself show the list:

default:
    @just --list

So a developer can clone the project and run:

just

to see what is available.

I like that because the task runner becomes a small piece of documentation.

But is `just` actually better than Make?

I'm not sure that's the right question.

Make is still a great choice in plenty of situations.

If I'm working on a project that already has a Makefile, I'm not going to suggest replacing it with just just because just is newer.

And if I'm writing something that needs to work in an environment where Make is already installed, that is a pretty good reason to use Make.

The thing I found interesting about just is that it feels more focused on the thing I was actually trying to do.

I wasn't building anything based on file timestamps.

I just wanted names for common commands and a way to combine them.

For that use case, just is pretty nice.

But it also comes with a trade-off. Unlike Make, you probably have to install it first.

So the comparison for me looks something like this:

	Make	just
Already installed	Often	Usually not
Task runner	Yes	Yes
Build system	Yes	No
`.PHONY`	Often needed	Not needed
Tab requirement	Yes	No
Task listing	DIY	Built in
Cross-platform	Possible	Designed for it

Neither one wins across the board.

Make has ubiquity.

just has a nice developer experience.

Which one makes more sense depends on the project.

There are other options too

Once I started looking into this, I found quite a few other tools doing roughly the same thing.

Task (go-task) was one I came across. It uses a YAML Taskfile.yml and has some useful features around variables and templating.

For Python, poethepoet was another interesting option. It lets you put tasks in pyproject.toml, which can be nice if you don't want another configuration file.

And if you're working in Node, npm scripts already give you a similar setup through package.json.

They all solve a similar problem.

You have a bunch of commands that developers need to run, and you give those commands names so people don't have to remember all the details.

The differences are mostly around syntax, ecosystem, and how much functionality you want.

So, am I switching to `just`?

For everything? No.

I'm still going to use Make.

If I open a project and there is a Makefile, I'll use it. If I'm working on infrastructure where Make is already expected, I'll probably use it there too.

But for projects I start myself, I can see myself reaching for just.

The thing I liked most was how little there was to learn.

My existing commands stayed exactly the same. I just put a small, readable interface around them.

That brought me back to why I started looking at this in the first place.

In Elixir, I'm used to having commands like:

mix ci

that give the project a simple interface for common development tasks.

With Python, I found myself wanting the same thing.

Make was one way to do it.

just is another.

I'm glad I spent the time learning it. Not because it replaced Make, but because now I know another tool that fits this particular problem really well.

And sometimes that's enough of a reason to try something new.

A Beginner’s Guide to Git and GitHub: From Installation to Your First Push

Mon, 12 Oct 2026 16:20:10 +0000

Starting my journey in Data Science, Analysis, and AI at LUXDevHQ felt like learning a new language while trying to build a house. One of the most important tools I’ve discovered along the way is Version Control.

In this guide, I’ll walk you through:

Setting up Git Bash
Connecting Git to GitHub
Mastering essential push and pull commands

1. What Is Git and Why Does It Matter?

Git is a Version Control System (VCS). Think of it as a save-point system for your code.

Why is Git important?

⏪ Time Travel – If you break your code, you can roll back to a version that worked.
🤝 Collaboration – Multiple people can work on the same project without overwriting each other’s work.
🧪 Experimentation – You can create branches to try new features without affecting the main project.

2. Setting Up Your Environment

Step A: Install Git Bash

Go to Git and download Git for your OS (I used Windows).
Run the installer.
💡 Pro tip: You can keep the default settings for most options.
After installation, search for Git Bash in your applications. It looks like a terminal window.

Step B: Configure Your Identity

To let GitHub know who is uploading code, configure your global Git settings:

git config --global user.name "Your Name"
git config --global user.email *Emails are not allowed*

3. Secure Your Connection: Setting Up SSH Keys

Using SSH is the professional standard. It’s more secure and saves you from typing your password every time you push code.

Step 1: Generate Your SSH Key

Open Git Bash and enter (replace with your GitHub email):

ssh-keygen -t ed25519 -C *Emails are not allowed*

•File Location: Press Enter to use the default location.
•Passphrase: As a beginner, I left this empty for convenience.

Step 2: Add Key to the SSH Agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Step 3: Add the Public Key to GitHub

1.Copy the key:

cat ~/.ssh/id_ed25519.pub

2.Go to GitHub: Settings → SSH and GPG keys → New SSH Key.

3.Give it a name (e.g., "My Learning Laptop") and paste your key into the "Key" box.

Step 4: Test the Connection

Run:

ssh -T *Emails are not allowed*

Success Check! If you see "Hi [YourUsername]! You've successfully authenticated", you are ready!

4. Navigating and Creating Your Project

Learning to navigate via Git Bash makes you much faster than using a mouse! Use these commands to create your first repository:
•Check Location: pwd (Print Working Directory).
•Go to Desktop: cd Desktop
•Create Folder: mkdir my-first-repo
•Enter Folder: cd my-first-repo

5. Tracking Changes (The Core Workflow)

Before sending code to GitHub, Git needs to "track" it locally. Run these inside your project folder:
1.Initialize Git: git init (Starts tracking the folder).
2.Check Status: git status (See what files Git notices).
3.Add Files: git add . (Stages all changes to be saved).
4.Commit: git commit -m "My first commit" (Creates the "save point").

6. Pushing Code to GitHub

Pushing sends your local save points to the cloud.

Step A: Create the Repository on GitHub.com

1.Log into GitHub, click the + icon → New repository.
2.Name it (e.g., my-first-project) and keep it Public.
3.Important: Leave "Add a README" unchecked to avoid conflicts.
4.Click Create repository.

Step B: Connect and Push

On the GitHub setup page, click SSH and copy the URL. Then run these commands one by one:

git remote add origin *Emails are not allowed*:your-username/repo-name.git
git push -u origin main

7. Pulling Code from GitHub

If you work on a different computer, use Pull to download the latest updates from the cloud:

git pull origin main

📚 Resources to Keep Learning

•Official Git Documentation
•GitHub Skills: Interactive Courses
•Visualizing Git Commands (Game)

Conclusion: Congratulations! You've just set up a professional dev workflow. Git can be tricky at first, but keep practicing and it will become second nature. If you ran into any issues, drop a comment below and let's help each other out!

Building CodeHarborHub: My Journey Toward Open-Source Developer Education

Thu, 08 Oct 2026 18:42:18 +0000

Introduction

Learning to code is easier when you have access to clear explanations, practical examples, and projects that help you apply what you learn.

But learning doesn't stop after completing a tutorial. Developers also need opportunities to practice, explore real-world problems, and contribute to meaningful projects.

That idea is one of the reasons I'm building CodeHarborHub, an open-source developer education platform.

Website: https://codeharborhub.github.io/

Why I'm Building CodeHarborHub

I want to help make modern technology easier to explore through practical learning resources and community-driven development.

CodeHarborHub brings together the idea of learning, building, and contributing. The goal is to create a place where developers can explore tutorials, understand programming concepts, work on projects, and participate in open source.

For me, the mission is not just to publish content. It's to encourage developers to move from reading about technology to actually building with it.

What I'm Working On

My work focuses on several areas:

Developer education: Creating structured tutorials and learning resources.
Web development: Building modern websites and developer-focused tools.
Open source: Encouraging contributions, collaboration, and shared learning.
AI-powered applications: Exploring practical ways to use AI in software products.

I'm also building projects such as AI Buddies and Algo, which reflect my interests in AI applications and problem-solving practice.

AI Buddies: https://ajay-dhangar.github.io/ai-buddies/

Algo: https://ajay-dhangar.github.io/algo/

Technology and Development

My current technical interests include JavaScript, TypeScript, React, Node.js, Tailwind CSS, Docusaurus, Supabase, and AI/LLM technologies.

I enjoy exploring how these tools can work together to build useful applications and accessible learning experiences.

The exact technology choices depend on the needs of each project. I believe in choosing tools that solve the problem rather than adding complexity without a clear benefit.

Why Open Source Matters

Open source creates opportunities to learn from other developers, review different approaches, improve documentation, and build software collaboratively.

It also allows learners to gain practical experience beyond isolated tutorials.

I want CodeHarborHub to support this spirit of collaboration by encouraging useful contributions and helping people learn from the process of building real projects.

What's Next?

I'm continuing to improve the platform, develop learning resources, and explore ways to make developer education more practical and engaging.

There is still plenty to learn and build. I see this as a long-term journey shaped by experimentation, feedback, and community participation.

Let's Connect

I'm always interested in connecting with developers, learners, open-source contributors, and people building useful technology.

Website: https://codeharborhub.github.io/
GitHub: https://github.com/Ajay-Dhangar
Portfolio: https://ajay-dhangar.github.io/
LinkedIn: https://www.linkedin.com/in/ajay-dhangar/

If you're building something in web development, AI, or open source, I'd love to hear about it.

What would make learning to code more practical and accessible for you?

Let's learn, build, and contribute together.

Use AI to Get Smarter, Not Lazier

Tue, 06 Oct 2026 18:40:48 +0000

I promise this isn't another post saying AI is making us dumber.

AI does make us faster, and we can't afford to give that up. But if you're not careful, "faster" quietly turns into "I shipped this and can't explain it". This post is about a way to use AI that keeps the speed and leaves you understanding what you did.

I'll explain the problem first, then walk through one of my day-to-day tasks, triaging static analysis (SAST) findings, done two ways: with a one-line "just triage it" prompt, and with AI used to help me understand. Both reach the same verdicts. Only one of them leaves me able to defend those verdicts.

Prefer video?

https://youtu.be/z_A_UVAFx0M

️ The long way is where the learning happens

Every task is a trip from "task" to "done". The long way is reading, searching, trying, failing and trying again. It's slow, but that's where you pick up tools, debugging habits, patterns, mental models, trade-offs and skills.

Humans take the path of least resistance, so we've always looked for shortcuts. Copying an answer from Stack Overflow was the classic one.

⚡ AI is the ultimate shortcut

Now a huge share of our tasks can be done, fully or partly, by telling AI: "do it for me". Most of the time the result is good enough.

That shortcut skips the long way entirely. We also can't simply refuse it: what's expected of us has gone up, because everyone can now get more done with AI.

️ Cognitive debt

Skip the learning once and nothing happens. But each time you take the shortcut, you finish a task without fully understanding how it works or why it was done that way. That gap is cognitive debt.

The debt stays invisible for a while. Then one day you hit a problem AI can't solve, and you have no idea where you are, where to start or where to go. We've all heard of codebases that were thrown away because rebuilding them was easier than understanding them, sometimes even for the AI that wrote them.

⚖️ The fix: a shortcut that balances doing and understanding

The answer isn't to stop using AI. It's to take a slightly longer shortcut, one that balances two things:

Doing: finishing the task, fast.
Understanding: knowing what was done, how, and why (the decisions and trade-offs), and learning to do it yourself.

You're still much faster than on the long way, but you arrive smarter instead of in debt.

You don't need to do this for everything. Set a threshold based on risk: a throwaway script can take the fast path. A decision you'll have to defend, like a security finding, can't.

The good news: AI is also very good at helping you understand. Here's what that looks like on a real task.

The demo: triaging Semgrep findings

The app is a small Express + PostgreSQL order tracker, built in layers like a real app: route → middleware → controller → service → repository. Customers list their orders, download CSV exports and leave comments. Admins see revenue reports.

Demo repo: mohamed-osama-aboelkheir/ai-sast-triage-demo. It's deliberately vulnerable. main is the clean app; reference-output has everything the AI produced in this post.

I ran Semgrep (the free p/default ruleset) and got a handful of findings, all marked as blocking:

SQL injection in orderRepository.js (ORDER BY ${orderBy})
SQL injection in reportRepository.js (FROM ${tableName})
Path traversal in exportService.js
XSS through an unescaped EJS tag in comments.ejs
No CSRF middleware in app.js

As an AppSec engineer, my job is to decide which are real, how severe they are, and which ones are worth an engineer's time. And let's say I don't know this codebase well.

⚡ Approach 1: "just triage it"

The shortest path: open Claude Code, paste the Semgrep output, and ask:

semgrep scan returned the below results, please triage the findings and let me know which are true and which are false positive, and suggest severity and fixes

A couple of minutes later I had a tidy answer:

SQL injection in ORDER BY: true positive, High
Path traversal in /exports: true positive, High
Table name in reportRepository: false positive
<%- %> XSS: false positive
Missing CSRF middleware: false positive

It's a good answer, and it even explains itself. But look at the two SQL injection findings:

// src/repositories/orderRepository.js — flagged
`SELECT id, total, status, created_at FROM orders
 WHERE user_id = $1 AND ($2::text IS NULL OR status = $2)
 ORDER BY ${orderBy}`

// src/repositories/reportRepository.js — flagged
`SELECT count(*)::int AS orders, coalesce(sum(total), 0) AS revenue FROM ${tableName}`

Same library, same pattern: a variable pasted into the SQL text. One is "High", the other is "false positive". If I don't know the codebase, I can't tell whether that's right. I could still copy the verdicts into tickets and move on. That's fast, and it's exactly how cognitive debt builds up. And the moment an engineer pushes back with "this isn't exploitable", I have nothing to say.

So let's take the two SQL injection findings and do it again, with AI helping me understand.

Approach 2: understand, trace, decide, prove

I packaged each step as a Claude Code skill in the appsec-skills plugin, so you can repeat it:

/plugin marketplace add mohamed-osama-aboelkheir/appsec-untangled-resources
/plugin install appsec-skills@appsec-untangled

Each step leaves a file you can read, check and reuse, not chat text you throw away.

1. ️ Understand: read the code like a story

Looking at the two flagged files on their own doesn't tell me much. What's orderRepository.find? Who calls reportRepository.summary? Code is written to be used by people, so the useful context is the story: which user action reaches this line, and what passes through on the way.

Let's start by understanding the context using the /appsec-skills:code-walkthrough skill to explain how the affected backend routes work, and how users interact with them.

The code-walkthrough skill produces two things for each flow:

a sequence diagram: one column per layer, a colour band per phase, for security controls, for untrusted input and ⚠️ for the sink;
a CodeTour file, a VS Code extension that walks you through the code step by step, the way the engineer who wrote it would. Step N in the tour is step N in the diagram.

Here's the story for GET /orders (the full diagram also covers the 401/400/500 exits):

Two steps stand out:

Step 8: the controller validates status against an allowlist, but sort is not checked.
Steps 9–10: sort is renamed orderColumn, then orderBy, on its way down to the query.

The second story, GET /reports/:reportId, is different. It needs an admin, and the controller uses reportId to look up an entry in a config object. Unknown IDs get a 404:

If you were paying attention, you may already see the difference. If not, that's what the next step is for.

2. Trace: source-to-sink

Source-to-sink analysis asks one question: does user input reach the dangerous function, and does anything stop it on the way?

Now using this context, perform the /appsec-skills:source-to-sink analysis for both findings, and share a verdict on whether each is a true or false positive.

The skill walks back from each sink, hop by hop. It draws one chain of code cards per source, with the value in bold on every line and arrows named after what the value is called next.

Finding 1: a red chain (user input) goes from req.query.sort straight to ORDER BY. The only check on the way () covers status, not sort:

Here's that path in the code (controller, service):

// src/controllers/ordersController.js
exports.list = async (req, res) => {
  const { status, sort } = req.query;
  if (status && !ALLOWED_STATUSES.includes(status)) {   // only status is checked
    return res.status(400).json({ error: 'invalid status' });
  }
  const orders = await orderService.search({ status, orderColumn: sort }, req.user);
  res.json(orders);
};

// src/services/orderService.js
exports.search = (filters, user) =>
  orderRepository.find(user.id, filters.status, filters.orderColumn || 'created_at');

$1 and $2 are bound parameters, but column names can't be bound, so ORDER BY ${orderBy} takes whatever the user sends. True positive.

Finding 2: the user's reportId stops ✋ at a lookup into a hard-coded object. The value that actually reaches FROM is a blue chain (config), not user input:

(controller, config)

// src/config/reports.js
module.exports = {
  daily:   { title: 'Orders in the last 24 hours', table: 'orders_daily_summary' },
  monthly: { title: 'Orders this month',           table: 'orders_monthly_summary' },
};

// src/controllers/reportsController.js
const definition = reports[req.params.reportId];   // input picks an entry...
if (!definition) return res.status(404).json({ error: 'unknown report' });
res.json(await reportService.build(definition));   // ...the table name comes from config

The user chooses which trusted value is used. They never supply SQL. False positive. It's still worth a low-priority fix (an allowlist, or Object.hasOwn, so /reports/constructor doesn't return a 500), but it's nowhere near as urgent as finding 1.

The two sinks look identical. Only the trace tells them apart.

I reached the same verdicts as the one-line prompt. The difference is that I can now defend them: I can show an engineer the exact path, the missing check and the fix.

3. Decide: an output template with evidence

That worked for two findings. To do it at scale, I use another trick: an output template. When I triage by hand, I look for the same things every time: the sink, the inputs that reach it, the path between them, the controls on that path, and then a verdict and a severity. So I make the AI fill in exactly those fields.

Now using this context, use /appsec-skills:semgrep-triage to triage both findings.

The semgrep-triage skill runs source-to-sink for every finding, checks each control against a wiki of mitigations and known bypasses, and writes one report. Here are the important parts for finding 1 (abridged):

F1 · SQL injection in ORDER BY via sort · ✅ True positive · High ⬆️

Inputs reaching it: req.query.sort (any logged-in user) reaches the sink unchanged; ⚪ 'created_at' is the constant default.
Controls on the path:
- requireAuth: decides who can send sort, not what it contains.
- Status allowlist: checks status only.
- Parameterised query: binds userId and status; identifiers can't be bound.
- Sort allowlist: none.
Severity: High = Impact High × Likelihood Medium. ORDER BY accepts sub-selects, so the row order becomes a yes/no oracle over the whole database, including the admin's API token. Any logged-in user can reach it.
Why Semgrep says less: the rule's MEDIUM/LOW is generic. It can't see that orderBy comes straight from the query string.
Suggested fix: an allowlist of sort columns, right next to the existing status check:

const SORT_COLUMNS = new Map([['total', 'total'], ['status', 'status'], ['created_at', 'created_at']]);

if (sort !== undefined && !SORT_COLUMNS.has(sort)) {
  return res.status(400).json({ error: 'invalid sort' });
}
const orders = await orderService.search({ status, orderColumn: SORT_COLUMNS.get(sort) }, req.user);

The part I care about most is Evidence (Manual Reproduction): the steps to reach the same conclusion myself, without trusting the AI.

Read the sink: src/repositories/orderRepository.js:7-11.
Find who calls it: grep -rn "orderRepository.find" src → orderService.js:4.
Find where orderColumn is set: grep -rn "orderColumn" src → ordersController.js:11, orderColumn: sort.
Find where sort comes from: ordersController.js:6, req.query. The only check (:7) is on status.
Find who can send it: routes/orders.js:5, requireAuth only.
Confirm locally: ?sort=total → 200 sorted by total; ?sort=price → 500, and the server log shows column "price" does not exist. The value reached the SQL text.

And for the false positive, the report doesn't just dismiss it. It says when it would become real, and what to do with the rule:

Would become a true positive if: tableName were ever taken from the request.
Rule decision: keep the rule enabled (it found a real bug in F1) and suppress this one instance with a comment that points to the triage.

The template does two things. It makes the AI follow the steps I would follow. (Without it, a model will often give a verdict, then admit "actually I didn't check X" when you push.) And it teaches me the pattern every time I read a report. If you'd like to test yourself first, run it with --learn: you give your own verdict, then compare.

4. Prove: an experiment instead of trust

Now the XSS finding. The template prints each comment unescaped:

<!-- src/views/comments.ejs:18 -->
<div><%- comment.html %></div>

<%- doesn't escape HTML, so Semgrep flags it. The triage traced user input from POST /comments to this line, and found one control on the way (source):

// src/utils/markdown.js
exports.render = (text) => DOMPurify.sanitize(marked.parse(text));

Verdict: false positive, because DOMPurify removes the payload. But say I've never used DOMPurify. Why is it enough? I could read the docs. Or I could ask AI to build me a small experiment I can run myself:

Create an /appsec-skills:security-experiment to explain how DOMPurify sanitize mitigates XSS with a simple example.

The security-experiment skill writes a Jupyter notebook (a Deno kernel, with the app's real library versions and its real template). It sends one classic payload through the app's steps, one cell per step, first without DOMPurify and then with it:

── Without DOMPurify ──
▶ marked.parse(text)
  <p>Package arrived damaged <img src="x" onerror="alert('XSS')"></p>
  ⚠️  dangerous: onerror="alert('XSS')"

── With DOMPurify ──
▶ DOMPurify.sanitize(html)
  <p>Package arrived damaged <img src="x"></p>
  ✅ nothing dangerous left

▶ what DOMPurify removed
  ✂️  onerror="alert('XSS')" from <img>: event handlers are not on its allowlist

The notebook ends with why that's enough (it runs on every render, after marked, as the last step before <%-) and what would break it (removing it, moving it to input only, changing the HTML after sanitising, or an outdated version with a known bypass). I saw the control work. I didn't just take its word for it.

✅ Same verdicts, very different engineer

After both approaches:

Approach 1 gave me verdicts in two minutes. I couldn't explain them, and the next similar finding would take just as long, because I learned nothing.
Approach 2 gave me the same verdicts with a few short prompts, plus:
- diagrams and tours of how the feature actually works;
- a trace showing exactly why two identical-looking findings differ;
- a report with reproduction steps and a tested fix I can hand to the engineer;
- an experiment that taught me how DOMPurify works.

I can now go to the engineering team with a priority I can stand behind: fix the ORDER BY injection now; the table-name pattern is a low-priority hardening task.

Takeaway

None of these techniques are specific to security. Wherever you use AI, you can ask it to:

Visualise: turn code into a diagram and a guided tour, so you read it as a story;
Trace: follow one value through the layers instead of trusting a summary;
Template: make it fill in the fields you would check yourself, with evidence;
Experiment: build something small you can run, to see the claim hold;
Quiz you: give your own answer first, then compare (--learn).

AI is a powerful tool, and using it does make you more efficient. Just keep an eye on the cognitive debt. Balance doing and understanding, so you're faster now and not stuck later.

Try it yourself

Demo app (deliberately vulnerable) and every AI output from this post: ai-sast-triage-demo
The skills: appsec-skills (code-walkthrough, source-to-sink, semgrep-triage, security-experiment). PRs are welcome.
More on YouTube: AppSec Untangled

How do you use AI to learn and not just to finish tasks? Tell me in the comments. I'd love to add more ideas to the skills.

The Forgetting Curve Everyone Cites Is Ebbinghaus's Own Column, Relabeled. The 90% Is Not in It.

Tue, 06 Oct 2026 13:19:27 +0000

Originally published at vibeagentmaking.com.

The "half in an hour, 70% in a day" figures that training blogs attribute to Ebbinghaus are his own column IV, a share of relearning time for lists of nonsense syllables, with the unit dropped. The 90% is not in his table; an exponential fits it five times worse than his 1885 formula; two replications confirm the shape.

On June 8, 2026, MeltingSpot's blog published a long post on the cost of forgetting in corporate training. Its first section, "What the Ebbinghaus forgetting curve actually tells us," reports what Hermann Ebbinghaus found: "roughly 56% is forgotten within one hour of learning, about 66% within one day, and around 75% within six days." Those figures are close to numbers Ebbinghaus printed. Two paragraphs later, in the same section, the post says that if a team finishes a Monday morning training and gets no review for the rest of the week, "cognitive science predicts that 90% of the material will be gone by Friday."

So 75% at six days became 90% at four, two paragraphs apart. The post then puts a price on it. Citing the Association for Talent Development's estimate that US organizations spend an average of $1,254 per employee per year on training, it says: "If 90% of that training content is not retained past the first week, the effective return on investment is not just low. It is catastrophic." The worked figure that follows is "roughly $940" wasted per employee. That is 75% of $1,254, the six-day number the post gave in its first section. Ninety percent would be $1,129.

The same figures run through the training industry's explainers. TalentLMS's blog says Ebbinghaus "found that within an hour of learning new information people tend to forget up to 50% of it. Within 24 hours, this can increase to 70%. By the end of the week, people tend to retain only about 25% of what they've learned." Further down, citing "studies" that illustrate the curve, it says people "tend to forget up to 90% of what they've learned within a month." The post dates from March 2023; the page was last modified on September 21, 2026. Today's Class says "on average we forget 50% of new information within an hour, and about 70% within one day," and "Within 30 days, we forget up to 90% of what we learned." TrainMeUK's headline from December 2025 is "Why Employees Forget 70% of Training in 24 Hours (The Ebbinghaus Effect)," and its introduction calls the forgetting "a biology problem."

We published a version of it too. An essay on this site in April said: "Hermann Ebbinghaus established the lower bound in 1885. Without reinforcement, humans lose roughly half of newly learned information within an hour and most of it within a week." This piece corrects that sentence, and the one after it, which went further.

What he measured

Ebbinghaus was his own and only subject. The seventh chapter of his book Memory, in the 1913 English translation by Henry Ruger and Clara Bussenius, gives the design: "The investigations in question fell in the year 1879-80 and comprised 163 double tests." Each double test meant learning eight series of 13 nonsense syllables (six, in 38 of the tests) until he could recite each series twice without error, then relearning them to the same standard after a fixed interval. He was 29.

He did not count the syllables he could still recall. He timed the relearning and took the time saved, as a share of the original learning time, as his measure: "This saving in work is each time the measure for the amount remembered at the end of the interval." If relearning a list took 60% as long as learning it, the saving was 40%.

He was also careful about whom the results described. Early in his discussion of them he writes that "it would be just as reasonable to be surprised at this initial rapidity and later slowness as they come to light here under the definite conditions of our experiment for a certain individual, and for a series of 13 syllables. One hour after the end of the learning, the forgetting had already progressed so far that one half the amount of the original work had to be expended before the series could be reproduced again; after 8 hours the work to be made up amounted to two thirds of the first effort."

That is where "half in an hour" comes from. Its unit is work.

The table

The summary table that closes Section 28 of the chapter has seven rows. Its second column is headed "So much of the series learned was retained that in relearning a saving of Q% of the time of original learning was made." Its fourth column is headed "The amount forgotten was thus equivalent to v% of the original in terms of time of learning," and every entry in it is 100 minus the second. The formula table in Section 29 gives the intervals in minutes, and they are less round than the summary suggests: the "1 hour" row was 64 minutes, and the "8.8 hours" row was 526.

Interval	Saving (column II)	Amount forgotten "in terms of time of learning" (column IV)
20 minutes	58.2%	41.8%
64 minutes	44.2%	55.8%
8.8 hours	35.8%	64.2%
1 day	33.7%	66.3%
2 days	27.8%	72.2%
6 days	25.4%	74.6%
31 days	21.1%	78.9%

Set the retellings beside it and most of their numbers turn out to be his. "Half in an hour" is 55.8% in column IV. "Seventy percent in a day" is 66.3%, rounded up. MeltingSpot's 56, 66 and 75 are column IV to the nearest point. TalentLMS's "about 25%" retained by the end of the week is column II at six days, 25.4%, copied correctly. Ebbinghaus made the conversion from savings to "forgotten" himself, in print.

What changed on the way is the thing the percentage is a percentage of. Column IV is the share of the original learning time that had to be spent again to relearn a list of nonsense syllables. The retellings make it a share of "new information," of "training content," of "what they've learned." A saving of 44.2% after an hour does not mean 55.8% of anything was lost. It means relearning took 55.8% as long as learning had.

Tom McDowall's critique in his Instructional Design Tips newsletter (November 2025) makes the savings point well, and says "you cannot legitimately convert savings scores into 'percentage forgotten.'" Ebbinghaus did convert them. He printed the result as column IV, with the unit in the heading. What later writers dropped was the unit.

The 90% has no source in the table. The largest value in column IV is 78.9%, at 31 days. At six days it is 74.6%. MeltingSpot's Friday, four days after a Monday session, falls between the two-day row (72.2%) and the six-day row (74.6%). TrainMeUK's "80% within a month" is near his 78.9%. The "up to 90%" within a month on TalentLMS and Today's Class is 11 points past it.

The shape

The retellings also name a shape. MeltingSpot: "memory of new material follows an exponential decay curve." Today's Class: "the percentage of information retained declined exponentially over time without reinforcement." McDowall's critique calls it "Ebbinghaus's exponential decline curve" too. An exponential loses a fixed fraction of what remains in each equal stretch of time.

We fitted that shape and two others to his seven savings values by least squares, with time in minutes. His own formula from 1885, with constants he set "with merely approximate estimates, not involving exact calculation by the method of least squares," misses his data by 1.73 percentage points, root mean square. A power law misses by 1.91. The best exponential misses by 9.10, more than five times the error of his hand-set formula.

The exponential cannot follow a curve that falls fast and then nearly stops. The best one starts at 40% saved and stays close to it through the first day: 39.9% at 20 minutes, where he measured 58.2%, and 38.8% at one day, where he measured 33.7%. It is too high at a week (32.4%, against 24.5% from his formula) and too low at a month (16.3%, against 21.3%). His own numbers drop 24.5 points between 20 minutes and one day, and only 4.3 points between the sixth day and the thirty-first. He named the pattern himself: "this initial rapidity and later slowness."

A 1996 survey points the same way. David Rubin and Amy Wenzel assembled 210 published data sets and fitted each "to 105 different 2-parameter functions." Their summary: "The best fits were to the logarithmic function, the power function, the exponential in the square root of time, and the hyperbola in the square root of time." The plain exponential is not among them.

Three people who ran it again

One subject invites the obvious question, whether his memory was unusual. In 2015 Jaap Murre and Joeri Dros of the University of Amsterdam repeated the experiment with Dros, then 22, as the only subject. "One subject spent 70 hours learning lists and relearning them," at Ebbinghaus's intervals, and "The results are similar to Ebbinghaus' original data." They set their results beside a German replication from 1991 by Heller, Mack and Seitz, with two subjects, which they describe as published only in German, without an English abstract, and never cited in international journals in English.

Their comparison table, in savings:

Interval	Ebbinghaus (1879–80)	Mack (1991)	Seitz (1991)	Dros (2015)
20 minutes	0.582	0.544	0.442	0.472
1 hour	0.442	0.432	0.325	0.373
9 hours	0.358	0.285	0.270	0.276
1 day	0.337	0.316	0.270	0.317
2 days	0.278	0.365	0.286	0.230
6 days	0.254	0.309	0.205	0.168
31 days	0.211	0.258	0.201	0.041

The shape holds for all four: a fast early drop, then a long shallow slope. At six days the largest loss in column-IV terms is Dros's, 83.2%. At 31 days, Mack is at 74.2% and Seitz at 79.9%, on either side of Ebbinghaus's 78.9%.

Dros at 31 days is the one number here that cuts against this essay. His saving of 0.041 is 95.9% in column-IV terms, past 90%. The authors treat it with care. His learning time rose by an average of 2.67 seconds a day per list over the 75 days of the experiment, which mostly affects the longest interval, and with a correction for that drift "the corrected savings measure would be 0.137 for the 31 day interval instead of 0.0410," which is 86.3%. That, they add, "is still well below the values for the three others." The Dros column above matches savings computed from the repetition counts in the paper's Table 1 at all seven intervals; computed from the seconds in its list-by-list Table 2, the 31-day saving is 0.090, or 91.0%. So there is a 90% in this literature: one subject, at one month, before the authors' correction for drift.

The replication also found something Ebbinghaus nearly discarded. In three of the four columns the one-day saving is at least as high as the nine-hour saving, which a curve that only runs downhill does not allow. The authors conclude that the curve "is not completely smooth but most probably shows a jump upwards starting at the 24 hour data point," and point to sleep: "The current body of research on sleep and memory would predict such a boost after one or two nights and attribute it to sleep, though for this particular type of experiments this has to established more firmly in further experiments." In Ebbinghaus's own table the one-day value sits 3.3 points above his formula, the largest miss of the seven, and he distrusted it. He wrote that it "would fit in well with the other observations to consider the number 33.7 per cent for the relearning after 24 hours as somewhat too large," and then that "it is upheld by observations to be stated presently, so that I am in doubt about it." He left it in.

What a saving is

The unit matters even though the shape replicates, because a saving and a recall score are different quantities. Murre returned to the measure in 2023 with Antonio Chessa. Ebbinghaus, they write, "measured memory retention in terms of the learning time saved in subsequent study trials relative to the time spent on the first learning trial," and they "prove mathematically that Ebbinghaus' savings measure is independent of initial encoding strength, learning time, and relearning times." They contrast it "with often used forgetting functions based on recall probability." A saving says how much faster the second learning went. It does not say what share of the material could still be produced on demand, which is what every retelling above takes it to say. And the material was lists of nonsense syllables.

What decades look like

Material that means something runs on a different clock. Harry Bahrick tested 733 people on the Spanish they had learned in school, across a span of 50 years, and published the results in 1984. "The analysis yields memory curves which decline exponentially for the first 3-6 years of the retention interval. After that retention remains unchanged for periods of up to 30 years before showing a final decline." Most had not kept it up: "The great majority of subjects rehearse so little that the data reveal no significant rehearsal effects." Retention over the whole period was "predictable on the basis of the level of original training," and "Large portions of the originally acquired information remain accessible for over 50 years in spite of the fact the information is not used or rehearsed."

Bahrick measured something different again, with tests of reading comprehension, recall and recognition, so his curves neither confirm nor overturn Ebbinghaus's. They show how far a table about nonsense syllables sits from a language learned in school.

Our April sentence

Here is the passage we published on April 26, 2026:

Hermann Ebbinghaus established the lower bound in 1885. Without reinforcement, humans lose roughly half of newly learned information within an hour and most of it within a week. Modern memory research has refined the curve in countless ways, but the directional finding has held up across 140 years of experiment. "We trained the team on the policy last quarter" is, neurologically, close to indistinguishable from "we never trained them."

The direction holds: both replications above found the fast early drop and the long flattening. The rest does not. "Humans" was one man, and he said so. "Newly learned information" was the time needed to relearn lists of nonsense syllables. "Most of it within a week" is true only in his unit, where it was 74.6% at six days. The chapter the numbers come from reports an average curve for one person and describes no lower bound. The last sentence is contradicted by the table it leans on: a month after learning, relearning still took 21.1% less time than learning had. Nothing in the experiment was neurological either; what he measured was time. And Bahrick's former students, most of whom rehearsed too little for it to show in the data, kept large parts of their Spanish for decades.

What the passage should have said: In 1879 and 1880, Hermann Ebbinghaus timed himself learning and relearning lists of nonsense syllables. An hour after learning a list, relearning it took about 56% as long as learning it had; a month later, about 79%. Replications in 1991 and 2015 found curves of the same shape.

Measuring your own

The part of Ebbinghaus a trainer can use is the method, and it needs a stopwatch. Time how long a group takes to reach a standard the first time: a procedure done without error, or a test passed. Some weeks later, before any refresher, time how long the same group takes to reach the same standard again. The time saved, as a share of the first session, is his measure for your material and your people. If the second session takes 70% as long as the first, the saving is 30%, and it is a number about your training.

Anyone who still wants to quote the 1885 figures can, with the qualifier Ebbinghaus attached to them: "for a certain individual, and for a series of 13 syllables."

The curve fits come from refit_ebbinghaus_c6733.py, which fits three shapes to the seven savings values in Ebbinghaus's summary table by least squares. Its first check is that his formula, as coded, reproduces the calculated values he printed in his formula table; it does, to within 0.1 point, but only with the exact 64 minutes from that table in place of a rounded hour, and that check is how the 64 minutes surfaced. Every quotation and figure above is checked against saved copies of its source by figures_c6733.py, which also recomputes the column-IV equivalents, the MeltingSpot arithmetic and the Murre and Dros savings from their Tables 1 and 2. Both scripts and their output are in one folder, with a list of every saved source the check reads, its public address, when it was saved and a checksum of the saved copy; the pages themselves are linked in the Sources below rather than republished. Ebbinghaus's tables are scanned images in the online edition; the values above were read off the scans, and his savings column agrees with Murre and Dros's transcription to the digit.

Part of Where the Number Came From, on how a published number is a fact about the way it was measured: Stanford says 12% to 66%, but 12% of what? · The safety score is a fact about the test rig · Tracing the 2026 AI-failure statistics to a primary

Sources:

Hermann Ebbinghaus, Memory: A Contribution to Experimental Psychology (1885), translated by Henry A. Ruger and Clara E. Bussenius (Teachers College, Columbia University, 1913), Chapter VII: Section 28 (the design; the definition of Q; the summary table that closes the section) and Section 29 (paragraphs 1 to 3, with the formula table of observed and calculated values). Classics in the History of Psychology, York University. https://psychclassics.yorku.ca/Ebbinghaus/memory7.htm
Jaap M. J. Murre and Joeri Dros, "Replication and Analysis of Ebbinghaus' Forgetting Curve," PLOS ONE 10(7): e0120644 (2015): abstract; Methods (the intervals, the subject, the differences from Ebbinghaus and from Heller et al.); Tables 1, 2 and 3; the paragraph after Table 3 (the drift correction); Discussion. https://doi.org/10.1371/journal.pone.0120644 (data: https://osf.io/6kfrp/)
O. Heller, W. Mack and J. Seitz, "Replikation der Ebbinghaus'schen Vergessenskurve mit der Ersparnismethode: 'Das Behalten und Vergessen als Function der Zeit'," Zeitschrift für Psychologie 199 (1991): 3–18. Values as reported in Murre and Dros, Table 3; the paper itself was not read.
Jaap M. J. Murre and Antonio G. Chessa, "Why Ebbinghaus' savings method from 1885 is a very 'pure' measure of memory performance," Psychonomic Bulletin & Review 30(1) (2023): 303–307, abstract. https://doi.org/10.3758/s13423-022-02172-3
Harry P. Bahrick, "Semantic memory content in permastore: Fifty years of memory for Spanish learned in school," Journal of Experimental Psychology: General 113(1) (1984): 1–29, abstract. https://doi.org/10.1037/0096-3445.113.1.1
David C. Rubin and Amy E. Wenzel, "One hundred years of forgetting: A quantitative description of retention," Psychological Review 103(4) (1996): 734–760, abstract (p. 734). https://doi.org/10.1037/0033-295X.103.4.734
Benoit Chatelier, "Forgetting curve corporate training: the real cost," MeltingSpot blog, June 8, 2026: the sections "What the Ebbinghaus forgetting curve actually tells us" and "The real financial cost of forgetting in L&D," and the paragraph before the second. https://meltingspot.io/en/blog/forgetting-curve-corporate-training
Athena Marousis, "What is the Ebbinghaus forgetting curve? Examples and strategies for overcoming it," TalentLMS Blog, March 30, 2023 (modified September 21, 2026): "What is the forgetting curve?" and the section after it. https://www.talentlms.com/blog/ebbinghaus-forgetting-curve/
David Boyes, "Fighting the Forgetting Curve," Today's Class blog, May 5, 2023 (modified April 28, 2025): the sections "What Is the 'Forgetting Curve'?" and "How Much Time Has Passed." https://www.todaysclass.com/blog/fighting-the-forgetting-curve
TrainMeUK, "Why Employees Forget 70% of Training in 24 Hours (The Ebbinghaus Effect)," December 3, 2025: headline and introduction. https://trainmeuk.co.uk/resources/ebbinghaus-effect-employees-forget-training-24-hours
Tom McDowall, "Sunday L&D Myth #4: People Forget 70% of What They Learn Within 24 Hours," Instructional Design Tips, November 9, 2025. https://idtips.substack.com/p/sunday-l-and-d-myth-4-people-forget
"We Wrote 25 Reminders and Made the Same Mistake Every Time," this site, April 26, 2026: the paragraph beginning "Hermann Ebbinghaus established the lower bound." https://vibeagentmaking.com/blog/we-wrote-25-reminders-and-made-the-same-mistake-every-time/

Keep the trail back to where the number was measured.

Every number in this piece survived because a script checks it against saved copies of its sources, so the trail from the figure back to the page it was measured on stays intact. A statistic that loses that trail, as "half in an hour" lost its unit, keeps its digits and changes its meaning. If you run agents that report numbers, keep the trail: Chain of Consciousness keeps a tamper-evident record of an agent's actions, so a figure it published can be traced back to what it actually read.

pip install chain-of-consciousness
npm install chain-of-consciousness

Or start without installing anything: Hosted Chain of Consciousness.

🚨 CSS Specificity — The Hidden Reason Your UI Breaks

Wed, 30 Sep 2026 16:07:21 +0000

Most developers learn CSS specificity once.

They remember:

#id > .class > div

Then move on.

Until one day…

Everything looks correct.

The CSS is present.

The selector is correct.

The z-index looks higher.

And yet the UI is broken.

That’s when CSS specificity stops being a beginner topic and becomes a production debugging problem.

The Production Incident That Started This

Recently, I was working on a microfrontend application.

Everything worked fine initially.

I opened a page, launched a modal and the UI looked correct.

Then I navigated to another microfrontend.

Its CSS got loaded.

After returning to the original microfrontend, suddenly:

❌ Modal appeared behind page content
❌ Overlay behaved incorrectly
❌ z-index looked correct but wasn't working

DevTools showed my CSS rule still existed.

Yet another CSS rule was winning.

The culprit?

CSS Specificity.

🧠 What is CSS Specificity?

CSS specificity is the algorithm browsers use to decide:

Which CSS rule wins when multiple rules target the same element.

Browsers don't simply apply:

"The last CSS rule."

That's one of the biggest misconceptions.

Specificity is calculated first.

Only when specificity is equal does source order become important.

⚔️ Example

.modal {
  z-index: 9999;
}

.some-library .modal {
  z-index: 100;
}

HTML:

<div class="some-library">
  <div class="modal"></div>
</div>

Many developers expect:

.modal

to win because the value is larger.

But CSS doesn't compare values first.

It compares selectors.

🧮 How Specificity Works

Specificity is usually represented as:

ID - CLASS - TYPE

Specificity Table

Selector	Specificity
`*`	0-0-0
`div`	0-0-1
`.modal`	0-1-0
`[type="text"]`	0-1-0
`:hover`	0-1-0
`#dialog`	1-0-0
Inline Style	Highest

MDN defines specificity as the weight browsers calculate to determine which declaration gets applied when multiple selectors match the same element.

Example Calculation

Selector:

button.primary

Contains:

button     → 0-0-1
.primary   → 0-1-0

Total:

0-1-1

Another selector:

#header button.primary

Contains:

#header   → 1-0-0
button    → 0-0-1
.primary  → 0-1-0

Total:

1-1-1

This selector wins.

❌ Myth #1 — Last CSS Always Wins

Many developers believe:

The CSS rule written last wins.

Not always.

Example:

#header {
  color: red;
}

div {
  color: blue;
}

HTML:

<div id="header">
  Hello
</div>

Result:

Red

Why?

Because:

#header = 1-0-0
div     = 0-0-1

Specificity wins before source order.

❌ Myth #2 — Higher z-index Always Wins

This causes countless production bugs.

Developers often write:

.modal {
  z-index: 99999;
}

And expect it to appear above everything.

Not necessarily.

Because:

z-index works inside stacking contexts.

🧠 What is a Stacking Context?

A stacking context is a separate layering environment.

Example:

.parent {
  position: relative;
  z-index: 1;
}

.child {
  position: absolute;
  z-index: 999999;
}

Even with:

the child cannot escape its parent's stacking context.

This is why modal, tooltip, dropdown, and popover bugs often feel confusing.

The Microfrontend Problem

This is where specificity becomes extremely important.

Imagine:

Microfrontend A

.modal {
  z-index: 9999;
}

Microfrontend B

.layout .modal {
  z-index: 100;
}

Specificity:

.modal
0-1-0

.layout .modal
0-2-0

Microfrontend B wins.

Even if your CSS is still loaded.

Why My Fix Worked

Originally:

.modal {
  z-index: 9999;
}

But another selector had higher specificity.

So I wrapped the modal:

<div class="dialog-wrapper">
  <Modal />
</div>

Then:

.dialog-wrapper .modal {
  z-index: 9999;
}

Before:

.modal
0-1-0

After:

.dialog-wrapper .modal
0-2-0

Now my selector became more specific and started winning.

The CSS value never changed.

Only specificity changed.

And the issue disappeared.

🚨 Why This Happens More in Microfrontends

Microfrontends often share:

Same DOM
Same global CSS
Same class names
Same browser environment

Problems include:

CSS leakage
Style collisions
Unexpected overrides
Load-order changes after navigation

This makes specificity bugs significantly more common.

Modern CSS Specificity Features Developers Often Miss

1️⃣ `:is()`

Example:

:is(.btn, .link)

The :is() pseudo-class itself doesn't add specificity.

Instead, it takes the specificity of the most specific selector inside it.

Example:

:is(.btn, #header)

Specificity:

1-0-0

Because:

#header

is most specific.

2️⃣ `:not()`

Many developers think:

:not(.hidden)

adds nothing.

Not true.

:not() itself doesn't contribute specificity.

But selectors inside it do.

Example:

:not(.hidden)

Specificity:

0-1-0

3️⃣ `:where()`

One of the most underrated CSS features.

Example:

:where(.btn)

Specificity:

0-0-0

Always.

:where() intentionally has zero specificity.

This makes it extremely useful for:

Design systems
Component libraries
Shared UI frameworks

Because consumers can easily override styles.

How to Debug CSS Specificity Issues

When CSS isn't applying:

Check these in order:

1. Is the rule present?

Open DevTools.

Verify the CSS exists.

2. Is it crossed out?

Crossed-out CSS usually means:

Another rule won.

3. Which selector is winning?

DevTools shows the winning selector.

Inspect it carefully.

4. Compare specificity

Many bugs become obvious here.

5. Check CSS load order

When specificity is equal:

Last rule wins.

6. Check stacking contexts

Especially for:

Modals
Dropdowns
Tooltips
Popovers

7. Check portals

React portals often render outside expected DOM hierarchy.

This changes how CSS behaves.

🎯 Best Practices

✅ Prefer class selectors over IDs

✅ Avoid deeply nested selectors

✅ Use low-specificity CSS in shared libraries

✅ Use :where() for easily overridable styles

✅ Be careful with global CSS in microfrontends

✅ Avoid excessive !important

Final Thoughts

Most developers think CSS specificity is a beginner topic.

In reality:

It's one of the most common reasons production UIs break unexpectedly.

Especially in:

Large applications
Design systems
Microfrontends
Shared component libraries

The tricky part is that the CSS often looks correct.

The rule exists.

The value is correct.

And yet another selector silently wins.

Understanding specificity deeply transforms CSS debugging from:

Trial and Error

into:

Predictable Engineering

Key Takeaways

CSS does not simply apply the last rule
Specificity determines which selector wins
Higher z-index does not always mean higher visibility
Microfrontends make specificity issues more common
:is(), :not(), and :where() have special specificity behavior
!important should be a last resort
DevTools can quickly reveal specificity conflicts when used correctly

Understanding CSS specificity is one of those skills that feels minor — until it saves you hours of debugging a production UI issue.

Arham Sayyed's Cybersecurity Workshop at ITM Skills University: Web Security, DevSecOps & Honeypots

Tue, 29 Sep 2026 20:13:45 +0000

Arham Sayyed, a Mumbai-based full-stack developer and security researcher, ran a three-part cybersecurity workshop on 7 September 2026 at ITM Skills University's School of Future Tech in Kharghar, in collaboration with Haxnation, for B.Tech students across three academic years. This post is a complete recap of what was actually taught, session by session: the tools used, the vulnerabilities demonstrated live, the exact mechanics behind each exploit, and the hands-on labs students worked through themselves.

Workshop information:

Instructor: Arham Sayyed
Organization: Haxnation
Venue: ITM Skills University's School of Future Tech, Kharghar
Date: 7 September 2026
Topics: Web security, SQL injection, Wireshark, DevSecOps, CI/CD security, GitHub Actions, honeypots, intrusion detection, detection engineering

The workshop ran as three separate sessions back to back: one for Second Year B.Tech students, one for Third Year B.Tech students under the Cybersecurity Specialization track, and one for Final Year B.Tech students, also under the Cybersecurity Specialization track. Six hours, three batches, one continuous idea running through all of it: security is something you learn by breaking things yourself, not by watching a slide deck describe someone else breaking them.

Arham Sayyed's Cybersecurity Workshop at ITM Skills University

ITM Skills University's School of Future Tech invited Arham Sayyed to bring a full day of hands-on cybersecurity training to its Kharghar campus, part of a broader push to give engineering students practical exposure to security work well before they graduate into it. Cybersecurity roles increasingly expect candidates to have touched real tools before their first job, not just studied the theory behind them, and a single elective course rarely covers the gap between "understands the OWASP Top 10 as a concept" and "has actually run a SQL injection payload against a real database."

Rather than a single generic talk, the day was structured as three distinct, escalating sessions, each scoped to where a batch actually was in its coursework, and each built around real, working tools rather than slideware standing in for them. Every session followed the same underlying philosophy: show a real exploit live, before any theory, then hand students the exact same environment to attack themselves. No simulations standing in for real vulnerabilities, no toy examples that don't map to anything real. Burp Suite, Wireshark, GitHub Actions, and a hand-built honeypot and intrusion detection system, all running for real, in front of the room.

What Is the Cybersecurity Specialization Track?

Third Year and Final Year batches at ITM Skills University's School of Future Tech follow a Cybersecurity Specialization track within their B.Tech program, a focused stream layered on top of the core computer engineering curriculum specifically covering security topics: network defense, application security, governance and compliance, and increasingly, the kind of DevSecOps and detection engineering skills covered in Sessions Two and Three of this workshop. Second Year students, not yet on the specialization track, received the foundational Session One instead, giving every batch content actually matched to their level rather than a single one-size-fits-all talk.

Session One: Web Security and Network Analysis

The first session ran for the Second Year B.Tech batch and covered web application security and network traffic analysis from the ground up, assuming zero prior security background, since this batch had not yet started the specialization track.

Arham Sayyed opened the session the same way a penetration test actually starts: a live login bypass, demonstrated before a single slide of theory. From there, the session built out the full picture, starting with the fundamentals almost nobody's coursework actually covers directly: what HTTP is, what a request and response actually contain, and why the protocol has no built-in memory of who you are between one page load and the next.

What a Proxy Is, and What Burp Suite Actually Does

Before naming any specific tool, the session covered what a proxy is in general: software that sits between a browser and a server and passes traffic through itself instead of letting it travel directly. Whoever controls that proxy can read, and critically, edit, traffic before it ever reaches the server it was addressed to.

Burp Suite, made by the UK security company PortSwigger, is a proxy built specifically for that second part, editing traffic on purpose, so a tester can study exactly what happens when a request is tampered with. It has been the default tool of the web application penetration testing industry since roughly the mid-2000s, and Burp Suite Community, the free edition used throughout this session, ships with an embedded Chromium browser already configured to route through the proxy, removing the usual fifteen minutes of manual certificate and proxy configuration that stalls most introductory Burp tutorials.

SQL Injection

Students then watched, and later reproduced themselves, a real SQL injection login bypass. The underlying mistake is almost always the same across real applications: a login check builds its database query by directly pasting submitted input into a string, rather than treating that input strictly as data. Typing ' OR '1'='1' -- into an email field, with any password at all, rewrites the query's logic entirely. The OR '1'='1' clause makes the WHERE condition true regardless of the actual credentials, and the trailing -- comments out the rest of the original query, including the password check itself, so it never runs. The result is a successful login as whichever user the database happens to return first, typically the administrator account.

Students then worked through a real SQL injection lab on PortSwigger's own Web Security Academy, the same free, industry-recognized platform used by professionals preparing for the Burp Suite Certified Practitioner exam. The specific lab, "SQL injection vulnerability allowing login bypass," uses the identical technique demonstrated live, in a fully isolated, disposable environment built for exactly this purpose.

Packet Analysis and the Real Difference Between HTTP and HTTPS

The second half of the session moved into network traffic analysis with Wireshark, free, open-source packet capture software that has been the default tool taught in networking courses worldwide since it was renamed from Ethereal in 2006. Students were walked through what a packet actually contains, a header describing where it came from and where it is going, and a payload carrying the actual content, before capturing a live login attempt themselves.

The centerpiece of this half was a live before-and-after demonstration: the exact same login form, submitted with the exact same credentials, once over plain HTTP and once over HTTPS. Over HTTP, filtering the capture and following the HTTP stream revealed the submitted username and password in fully readable plain text. Over HTTPS, the same filter on the same login showed nothing but ciphertext, because a TLS handshake had already encrypted the connection before a single byte of the actual form data left the browser. One honest caveat came with it: HTTPS defeats a packet sniffer sitting outside the machine, but does nothing about a proxy like Burp Suite, which the browser was explicitly configured to trust.

Students closed out Session One with hands-on networking challenges on a capture-the-flag platform, applying the same filter-and-follow-stream technique against real capture files to reinforce the skill in a graded, self-paced environment.

Topics covered in Session One:

HTTP fundamentals: requests, responses, and statelessness
What a proxy is, and why Burp Suite is built around that concept
Burp Suite fundamentals and web exploitation
Hands-on SQL injection, including a live login bypass and its exact mechanism
PortSwigger Web Security Academy labs
Packet analysis with Wireshark
HTTP vs HTTPS, and what a TLS handshake actually changes
Hands-on capture-the-flag networking challenges

Session Two: DevSecOps and CI/CD Pipeline Security

The second session was delivered to the Third Year B.Tech batch under the Cybersecurity Specialization track, and shifted focus from web applications to CI/CD pipelines, treating the build pipeline itself as a genuine attack surface rather than deployment plumbing that happens to exist alongside the real application.

Two Buckets, Six Pillars

The session opened with a framing carried through the rest of the day: every pipeline compromise is either unauthorized tampering, someone changing what gets built or how, or unauthorized disclosure, something leaking that should not have. Six specific pillars of pipeline security were mapped across those two categories: build source, build process, build server, and build pipeline under tampering; build environment and build secrets under disclosure.

Two of those pillars were covered as concept-only stories, since neither is safe to demonstrate hands-on. Dependency confusion, the build process risk, was explained through Alex Birsan's well-documented 2021 research, in which publishing a public package under the same name as a company's internal package caused package managers to silently prefer the attacker's version over the real one, affecting real companies including Apple, Microsoft, and PayPal. The build server risk was explained through the well-known danger of an exposed, unauthenticated Jenkins script console, which hands an attacker direct code execution on infrastructure that usually holds real deployment credentials.

A Pipeline That Looks Completely Green

The live demonstration opened with a pipeline that looked entirely normal, every check passing, nothing flagged, and then walked through exactly why that signals less than it appears to. Students were shown a real, planted secret still recoverable from git history long after the file that originally introduced it had been deleted in a later commit, since deleting a line from the working tree never deletes the commit that added it. Anyone running git log -p against the full history, or using GitHub's own commit search, could recover it in seconds.

Two more disclosure mechanisms were demonstrated: a secret printed in full, plain text into a GitHub Actions log through a debug line, because GitHub only automatically masks values that have been explicitly registered as secrets, never plain environment variables, no matter how sensitive their name sounds. And a secret shipped unintentionally inside a downloadable build artifact, generated at build time and swept up by a packaging step that copied everything in an output folder without anyone deciding that on purpose.

Every vulnerability was paired immediately with its fix. Automated secret scanning with a tool like gitleaks, added as a single workflow step, catches both the git-history leak and the log leak at once, since it scans committed workflow content as well as commit history. Branch protection requiring a genuine second reviewer, with the author's own approval explicitly excluded from satisfying that requirement, closes the segregation-of-duties gap that exists by default on any fresh repository or personal fork.

A Real Repository, Forked and Fixed

Students then forked a real, purpose-built vulnerable pipeline repository, containing the exact issues demonstrated live, and worked through finding and fixing each one themselves. Submissions were validated live against a shared leaderboard built entirely on GitHub Issues and GitHub Actions: each issue template mapped to one vulnerability class, an automated workflow checked the submitted flag against a stored value, and a correct answer closed the issue automatically with a live-updating rank.

Topics covered in Session Two:

The two-bucket framing: unauthorized tampering vs unauthorized disclosure
Dependency confusion and real-world supply chain attacks
Exposed Jenkins script consoles and build server risk
Segregation of duties and branch protection
Recovering secrets from git history after deletion
GitHub Actions log masking, and exactly where it does not apply
Secrets leaking through downloadable build artifacts
Automated secret scanning with gitleaks
Hands-on exploitation and remediation of a live, forkable vulnerable pipeline

Session Three: Honeypots and Intrusion Detection

The final session, for Final Year B.Tech students under the Cybersecurity Specialization track, went furthest into building rather than using existing security tooling, and closed the day by tying every hour of it back to real industry practice.

What a Honeypot Actually Is

A honeypot is a target that exists purely to be attacked. It has no real users and no real data, so any traffic it receives is either a mistake or an attacker, with nothing in between, which makes everything a honeypot logs suspicious by definition. The session distinguished low-interaction honeypots, which fake just enough to be convincing, from high-interaction honeypots, which run genuine software and accept real risk to capture more detail, and explained why the low-interaction approach was the deliberate choice for this exercise.

Rather than installing an existing honeypot framework, students were given a small web application, built with Express and backed by an embedded SQL engine, containing three vulnerabilities: SQL injection on the login form, weak, guessable admin credentials, and stored cross-site scripting through a guestbook feature that rendered submitted messages with zero output escaping. Alongside it sat a second, hardened server: the same login flow, but with a properly hashed password and a parameterized query, so the identical SQL injection payload that worked against the honeypot did nothing against it, a direct, visible contrast between vulnerable and secure code handling the exact same logic.

Students extended the honeypot with vulnerabilities of their own choosing before a few were called up to demonstrate what they had added, with the strongest additions merged into one shared honeypot that, by the end of the session, had genuinely been built collectively by the room.

From Signature Detection to a Real Threshold Rule

The second half of the session covered intrusion detection from first principles: signature-based detection, matching traffic against a library of known-bad patterns; anomaly-based detection, flagging deviation from a learned baseline of normal behavior; and threshold-based detection, simply counting events and firing once a number is crossed within a time window. Students were shown that a genuinely large share of real production alerting is built on the third, simplest category, not the more sophisticated-sounding first two.

Every request against the honeypot was tagged with an anonymous session identifier, assigned on first contact through a cookie rather than relying on IP address, since every attacker in the same room shares an IP on a shared network. Students then examined a hand-written, JavaScript-based intrusion detection script watching the honeypot's activity log in real time, implementing a single rule: five or more login attempts from the same session within ten seconds triggers an alert.

A live, fast attack against the honeypot triggered that alert within seconds of the fifth attempt. A second attack, run against the exact same target with the exact same wordlist, was then paced deliberately at three-second intervals instead, and slipped entirely underneath the same threshold, twelve attempts, zero alerts, an honest and real limitation of threshold-based detection rather than a flaw in the exercise, and exactly the gap that real attackers who understand detection systems deliberately exploit.

Mapping the Day Back to the Real Industry

The session closed by naming the real tools every piece of the day's exercise mirrors at production scale: Cowrie and T-Pot as real honeypot platforms used in SOC training and research, GreyNoise as a commercial company built entirely on turning honeypot telemetry into a threat intelligence product, Snort, Suricata, and Zeek as real network intrusion detection engines, and Wazuh and fail2ban as the closest real analogues to the hand-written detection script, both fundamentally watching a log and counting events past a threshold. Sigma, a platform-agnostic format for writing detection logic once and translating it into whatever query language a given SIEM platform speaks, was shown directly alongside the session's own JavaScript threshold rule to make the mapping concrete rather than asserted. The session's brute-force detection was tied to MITRE ATT&CK technique T1110, the shared, precise vocabulary security teams worldwide use to describe this exact behavior, and the day closed by naming the career paths this kind of work leads into: SOC Analyst, Detection Engineer, and Threat Hunter.

Topics covered in Session Three:

What a honeypot is, and low interaction vs high interaction design
Building a web honeypot with Express: SQL injection, weak credentials, stored XSS
A hardened comparison server, and exactly what makes it hardened
Anonymous session tracking and full activity logging
Signature-based, anomaly-based, and threshold-based intrusion detection
Writing a JavaScript-based threshold detection script from scratch
Simulating live attacks and triggering real-time alerts
Testing slow-rate attacks designed to evade threshold detection
Real industry tools: Cowrie, T-Pot, GreyNoise, Snort, Suricata, Zeek, Wazuh, fail2ban
Sigma detection rules and the MITRE ATT&CK framework
Career paths: SOC Analyst, Detection Engineer, Threat Hunter

Frequently Asked Questions

What is a honeypot in cybersecurity?
A honeypot is a decoy system with no real users or data, deployed specifically to attract and record attacker behavior. Because it serves no legitimate purpose, any traffic it receives is inherently suspicious, making it a useful, low-noise source of real attack data.

What is DevSecOps?
DevSecOps is the practice of integrating security checks directly into the software development and deployment pipeline, rather than treating security as a separate, later stage. It covers securing the source code, the build process, the build server, the pipeline configuration itself, the deployment environment, and any secrets or credentials the pipeline handles.

What is SQL injection?
SQL injection is a vulnerability where user-supplied input is inserted directly into a database query without being properly separated from the query's actual logic, allowing an attacker to alter what the query does, commonly used to bypass login forms or extract data the application was never meant to expose.

What is an intrusion detection system (IDS)?
An intrusion detection system monitors activity, whether network traffic or system logs, for signs of malicious behavior, using signature matching, anomaly detection, or threshold-based rules, and raises an alert when it finds something worth a human's attention.

What is the difference between HTTP and HTTPS?
HTTPS is HTTP with an additional encryption layer, TLS, negotiated before any application data is sent. HTTP traffic travels in plain, readable text; HTTPS traffic is encrypted end to end between browser and server, though it does not protect against something running locally on the same machine, such as a trusted proxy.

Hands-On Cybersecurity Training, Start to Finish

Across all three sessions, the format stayed consistent: an exploit demonstrated live first, the underlying concept explained second, and a genuine hands-on lab third, whether that meant a PortSwigger Web Security Academy lab, a forkable vulnerable GitHub repository, or a self-built honeypot and detection script. Nothing in any of the three sessions ran as a simulation standing in for the real thing, and every piece of infrastructure used across the day, from the Burp Suite setup to the vulnerable pipeline repository to the honeypot's embedded database, was tested end to end in advance.

Thank You

A huge thank you to Ayaan, who was there through all three sessions, helping keep everything running smoothly from setup to wrap. Thank you as well to ITM Skills University and the School of Future Tech for hosting the day, and to every student across all three batches, Second Year, Third Year, and Final Year B.Tech, who showed up, asked sharp questions, and actually broke things.

About Arham Sayyed

Arham Sayyed is a Mumbai-based full-stack developer, security researcher, and cybersecurity educator, working across MERN, TypeScript, and Next.js in both product development and freelance client work. He lectures on cybersecurity and related subjects for BSc CA/BCA students under the Mumbai University NEP syllabus, and builds practical cybersecurity training infrastructure, including the vulnerable pipeline repository and the honeypot and intrusion detection setup used in this workshop. He is a Platform Engineering Volunteer at Haxnation, a cybersecurity community running a CTF platform, meetups, and workshops like this one.

Connect with Arham Sayyed on GitHub or X.

Going Back to TypeScript Basics

Sat, 26 Sep 2026 09:17:06 +0000

After finishing my JavaScript refresher, TypeScript was next.

I’ve used TypeScript before, so I went into this thinking it would mostly be a case of reminding myself of things I already knew.

That was partly true.

The basic stuff came back pretty quickly. Types on variables, functions, arrays, objects — nothing too surprising there.

const memberCount: number = 10;

function isAdmin(role: string): boolean {
    return role === "admin";
}

But as I went further, I started noticing the same thing that happened during my JavaScript refresher.

There’s a difference between recognising something and actually understanding it.

I could look at a generic and think, yeah, I know what that is. But could I write one myself? Could I explain why I needed it? Could I tell when I didn't need one?

Not always.

And that’s really why I wanted to do this refresher in the first place.

TypeScript started making more sense when I stopped fighting it

One thing that became clearer this time was type narrowing.

Say I have:

interface Member {
    name: string;
    profilePicture: string | null;
}

I can't just do:

member.profilePicture.toUpperCase();

because TypeScript doesn't know whether profilePicture is actually a string.

My first instinct in the past would've probably been something along the lines of, I know it's a string here, why are you complaining?

But that's the point.

I might know what I expect the value to be. TypeScript wants me to prove it.

if (member.profilePicture !== null) {
    member.profilePicture.toUpperCase();
}

Once I started looking at narrowing like that, it stopped feeling like TypeScript getting in my way.

The same thing happened with .find().

function findMember(
    members: Member[],
    name: string
): Member | undefined {
    return members.find((member) => member.name === name);
}

I might expect the member to exist, but .find() doesn't care about my expectations. It can return undefined.

So the type should say that.

Simple, but important.

Generics weren't as scary as they looked

Generics were another one.

This:

function getLast<T>(items: T[]): T | undefined {
    return items[items.length - 1];
}

used to look more complicated than it actually is.

Once I started thinking of T as basically saying “whatever type you give me”, it became much easier to read.

Give it strings?

T is a string.

Give it numbers?

T is a number.

Give it members?

T is a Member.

Then we got to things like:

function getPostValue<K extends keyof Post>(
    post: Post,
    key: K
): Post[K] {
    return post[key];
}

Now, I'll admit, something like this still looks a bit mad when you first see it.

But breaking it apart helped.

keyof Post gives me the valid keys from Post.

K is one of those keys.

Post[K] is the type of whatever property I asked for.

So if "title" points to a string, TypeScript knows I'm getting a string back. If "likes" points to a number, I get a number.

It wasn't really about memorising the syntax. It was understanding what each part was trying to describe.

I managed to confuse Pick and Omit

We also went through TypeScript's utility types: Partial, Pick, Omit and Record.

Most of it was straightforward.

Then I got asked something like:

If you only want title, company and salary from a Job type, which utility type would you use?

I said Omit.

My reasoning?

Because I only wanted title, company and salary.

Which is literally the reason I should have used Pick.

😂

That mistake actually made the difference easier to remember than just reading the documentation would have.

Pick what you want to keep.

Omit what you want to remove.

Sometimes getting something wrong once is all it takes.

Then things started connecting

Discriminated unions were where TypeScript started feeling less like “adding types to JavaScript” and more like actually modelling how an application works.

For example:

type MemberState =
    | { status: "loading" }
    | { status: "success"; members: Member[] }
    | { status: "error"; message: string };

If the status is "success", TypeScript knows there are members.

if (state.status === "success") {
    console.log(state.members);
}

If it's "error", TypeScript knows there's a message.

And if it's "loading", neither of those things should exist yet.

That makes sense because that's how the application actually behaves.

We also looked at never for checking that every possible state has been handled.

That was when I started seeing that a lot of these TypeScript features aren't really separate things.

They build on each other.

Union types lead to narrowing.

Narrowing makes discriminated unions useful.

Discriminated unions make exhaustive checking possible.

The individual syntax started mattering less than the relationship between everything.

Type predicates were another good example

We wrote things like:

function isAdmin(user: User): user is Admin {
    return user.role === "admin";
}

The interesting bit for me was:

user is Admin

We're not just returning true or false.

We're telling TypeScript:

If this function returns true, I've checked this value and you can treat it as an Admin.

That's powerful, but there's also a catch.

TypeScript trusts you.

If the function says user is Admin but my actual logic checks for a member instead, TypeScript isn't going to magically save me.

I'd basically be lying to the compiler.

That distinction between what TypeScript can check and what my code still needs to get right came up again later.

API data made `unknown` click for me

This was probably one of the most useful parts of the refresher.

Imagine I do this:

const data: Member[] = await response.json();

It looks nice.

My editor is happy.

TypeScript thinks I have an array of members.

But what if the API sends something completely different?

Writing Member[] doesn't magically transform the response into valid member data.

I'm basically just telling TypeScript to trust me.

A safer starting point is:

const data: unknown = await response.json();

Now I have to prove what the data actually is before using it.

We ended up building a validator manually:

function isMember(value: unknown): value is Member {
    if (typeof value !== "object" || value === null) {
        return false;
    }

    if (!("name" in value) || typeof value.name !== "string") {
        return false;
    }

    if (!("id" in value) || typeof value.id !== "number") {
        return false;
    }

    if (
        !("role" in value) ||
        (value.role !== "admin" && value.role !== "member")
    ) {
        return false;
    }

    if (
        !("isOnline" in value) ||
        typeof value.isOnline !== "boolean"
    ) {
        return false;
    }

    return true;
}

And, of course, I got some of the logic wrong at first.

I was doing something similar to:

if (("id" in value) && typeof value.id === "number") {
    return true;
}

In my head I was checking that the id was valid.

Which I was.

The problem was that I was then returning true for the entire object.

So apparently having a valid ID was enough to become a valid member. Name? Role? Online status?

Who needs those? 😂

The better way was:

if (!("id" in value) || typeof value.id !== "number") {
    return false;
}

Check each reason the object could be invalid, reject it when something is wrong, and only return true once it survives all the checks.

That wasn't even really a TypeScript problem.

It was a logic problem.

And that's exactly the kind of thing I wanted this refresher to expose.

By the end, the types were doing something useful

Towards the end, I had to model members and admins.

My first attempt was:

type Role = "admin" | "member";

interface Member {
    id: number;
    name: string;
    role: Role;
    isOnline: boolean;
}

interface Admin extends Member {
    permissions: string[];
}

Looks reasonable.

Except there's a problem.

Because Admin inherits role: Role, this is technically possible:

const admin: Admin = {
    id: 1,
    name: "Sabi",
    role: "member",
    isOnline: true,
    permissions: ["delete-post"]
};

An admin whose role is "member".

Not exactly ideal.

So we changed the model:

interface BaseUser {
    id: number;
    name: string;
    isOnline: boolean;
}

interface Member extends BaseUser {
    role: "member";
}

interface Admin extends BaseUser {
    role: "admin";
    permissions: string[];
}

type User = Member | Admin;

Now an Admin has to be an admin.

A Member has to be a member.

Then I could write:

function getOnlineAdmins(users: User[]): Admin[] {
    return users.filter(
        (user) => user.role === "admin" && user.isOnline
    );
}

It's a small example, but I think it sums up what I've taken from this refresher.

Before, I probably would have looked at TypeScript mainly as a way of saying:

name: string
age: number
isOnline: boolean

That's part of it.

But good types can describe much more than that.

They can describe what states are possible, what data might be missing, what kind of user you're dealing with, what a function actually returns and what your application should and shouldn't allow.

So, do I know TypeScript now?

More than I did before.

Everything? Definitely not.

There are still advanced parts of TypeScript that I haven't touched, and I'm sure I'll run into plenty of things that make me stare at my screen wondering what on earth I'm looking at.

But I don't think I need to know all of TypeScript before moving forward.

That wasn't the point.

The point was to get comfortable enough with the fundamentals that when I start using TypeScript properly with React, I'm not just adding types until the red lines disappear.

More importantly, I'm starting to understand what TypeScript is trying to tell me when those red lines appear.

JavaScript refresher done.

TypeScript refresher done.

Now, React.

Personal Expense Tracker V2 — Edit, Validation & Error Handling

Tue, 22 Sep 2026 17:19:39 +0000

I’ve completed V2 of my Personal Expense Tracker

This project started as a way to practice Python OOP, SQL, and SQLite by building something practical instead of only studying theory.

V1 focused on getting the core CRUD operations working.

With V2, I focused on making the application more reliable and user-friendly.

What I Added in V2

✏️ Edit Expenses

Users can now modify an existing expense.

The edit flow allows changing:

Amount
Category
Description
Date
Cancel the operation

This also gave me more practical experience working with SQL UPDATE statements and designing application flow around user choices.

️ Input Validation

I also added validation for user input.

The application now handles things such as:

Invalid menu choices
Invalid amount input
Negative or zero amounts
Invalid category selection
Empty descriptions
Invalid dates
Impossible dates such as 2026-02-30

For example, instead of allowing invalid input to crash the program, the application asks the user to provide a valid value.

⚠️ Error Handling

While implementing validation, I also started thinking more carefully about where errors can happen and how the application should respond.

One important lesson was that input validation is not just about preventing crashes.

It is about defining what the application considers valid input and controlling the flow when the user provides something unexpected.

What I Learned

V2 taught me more than just how to add an edit feature.

I learned about:

Designing validation rules before implementing them
Using try/except for user input
Separating application flow from business logic
Handling different types of invalid input
Thinking about edge cases
Designing better CLI user interaction
Keeping the project scope under control

One thing I learned during this version is that not every possible improvement needs to be implemented immediately.

There are still things I could add, such as more advanced database error handling and additional checks, but I decided to stop V2 at the scope I originally defined.

That is also part of learning software development: knowing when a version is complete.

️ Current Architecture

The project currently follows a simple separation of responsibilities:

main.py
   ↓
ExpenseManager
   ↓
Database / storage.py
   ↓
SQLite

main.py handles the CLI/application flow, ExpenseManager handles the application logic, and storage.py handles database operations.

V2 Status

V2 is now complete.

The project currently supports:

✅ Add expenses
✅ View expenses
✅ Edit expenses
✅ Delete expenses
✅ Category selection
✅ Input validation
✅ Date validation
✅ Basic error handling

The main goal of this version was not to build a huge application.

It was to take the working V1 and make it more reliable while strengthening my understanding of Python, OOP, SQL, SQLite, and application design.

Project

GitHub Repository: Personal Expense Tracker

I’ll continue improving the project in future versions when there is something meaningful to learn or add.

Thanks for reading!

Personal Expense Tracker — V1 Complete: Building the Core Working Stage

Tue, 22 Sep 2026 17:10:47 +0000

I’ve completed V1 of my Personal Expense Tracker, a small learning project built with Python and SQLite.

This project was created primarily to learn by building rather than following a tutorial step by step.

The goal of V1 was not to build a production-ready expense tracker.

The goal was:

Build the core application flow, understand the responsibilities of each layer, and make the fundamental functionality work end-to-end.

With that goal achieved, I consider V1 complete.

Why I Built This Project

I wanted to strengthen my understanding of:

Python OOP
Classes and objects
Object responsibilities
SQL and SQLite
CRUD operations
Database design
Separating application responsibilities
How different layers communicate with each other

Instead of learning these concepts separately, I decided to combine them into one small practical project.

That's why I consider this primarily a learning project.

The objective was not to create a feature-rich application immediately, but to understand the fundamentals by actually building something.

What I Built

The application is a command-line Personal Expense Tracker.

The core V1 functionality includes:

Adding an expense
Viewing expenses
Deleting an expense
Storing expenses in SQLite
Using SQLite-generated IDs
Separating the application into different responsibilities

The database currently contains an expenses table:

Column	Type
`id`	INTEGER PRIMARY KEY
`amount`	REAL
`category`	TEXT
`description`	TEXT
`date`	TEXT

Application Architecture

One of the main things I wanted to learn was how to organize responsibilities in an application.

I structured the project into three main layers:

main.py
   ↓
ExpenseManager
   ↓
Database
   ↓
SQLite

`main.py` — UI Layer

main.py is responsible for interacting with the user through the CLI.

Its responsibilities include:

Displaying the menu
Taking user input
Calling the appropriate operation
Displaying results

The UI does not directly handle SQL operations.

`expense_manager.py` — Application Layer

ExpenseManager acts as the middle layer between the UI and storage.

It coordinates application operations and communicates with the database object.

For example:

main.py
   ↓
ExpenseManager.add_expense()
   ↓
Database.insert_expense()

This helped me understand the difference between the application's operation and the actual persistence of data.

`storage.py` — Persistence Layer

The Database class handles communication with SQLite.

Its responsibilities include:

Creating the database connection
Initializing the database
Creating the table
Inserting expenses
Retrieving expenses
Deleting expenses

This keeps database-related responsibilities separate from the UI.

Understanding Object Relationships

Another important part of this project was understanding how objects can work together.

The application creates a database object and passes it to ExpenseManager.

Conceptually:

main.py
   │
   ├── creates Database
   │
   └── creates ExpenseManager
             │
             └── uses Database

The manager receives the database dependency instead of creating its own database internally.

This was one of the OOP concepts I wanted to understand through practical implementation.

Why V1 Is Complete

There is an important distinction between:

"V1 is complete"

and

"the project is finished."

V1 is complete because its intended scope has been achieved.

The core application flow works:

User
 ↓
CLI
 ↓
ExpenseManager
 ↓
Database
 ↓
SQLite

An expense can be added and stored, stored expenses can be retrieved and displayed, and expenses can be deleted.

The different layers can communicate with each other correctly.

That is the foundation I wanted to establish in V1.

What I Learned From V1

The biggest lesson wasn't simply learning SQLite syntax or Python syntax.

It was understanding responsibility.

I learned to think about the application as separate parts with different jobs:

UI
→ communicates with the user

Manager
→ coordinates application operations

Storage
→ communicates with the database

Along the way, I gained practical experience with:

Python classes
Constructors and attributes
Methods
Object relationships
Passing dependencies between objects
SQLite tables
Primary keys
CRUD operations
SQL queries
Multi-module Python projects
Debugging
Git and GitHub

What I Didn't Focus On in V1

I deliberately didn't try to make V1 handle every possible invalid input or edge case.

Comprehensive validation and robust error handling were not the main goals of this version.

Instead, I decided to make the core functionality work first and move robustness-related improvements into V2.

This gives the project a clearer progression:

V1
Core Working Stage
       ↓
V2
Robustness + Additional Core Operation

What's Coming in V2?

Now that the core working stage is complete, V2 will focus on improving the application's robustness and functionality.

The planned V2 work includes:

Validation

Validating user input
Validating expense IDs
Handling invalid values
Handling invalid menu input

Error Handling

Handling invalid user input gracefully
Handling invalid/non-existent expense IDs
Handling database-related errors
Providing better user-facing error messages

Edit Expense

V2 will also introduce an Edit Expense operation.

The core expense operations will then become:

Create
Read
Update
Delete

or simply:

CRUD

This will make the expense management functionality more complete.

V1 → V2

The project's progression can be summarized as:

V1
│
├── Add Expense
├── View Expenses
├── Delete Expense
├── SQLite persistence
├── Layered architecture
└── Core application flow
        │
        ▼
V2
│
├── Edit Expense
├── Input validation
├── ID validation
├── Error handling
└── CLI refinement

I intentionally want to keep these stages separate.

V1 proves that the foundation works.

V2 will make that foundation more robust and complete.

Final Thoughts

This project started as a learning exercise to understand Python OOP and SQLite by building something practical.

Completing V1 gave me more than just another project for my GitHub repository.

It helped me understand how a small application can be divided into responsibilities and how those components communicate with each other.

I'm treating V1 as a completed learning milestone, not as the final state of the application.

The core working stage is done.

Project

GitHub Repository: Personal Expense Tracker

Now it's time to build on that foundation.

V1: Complete.

Core working stage: Achieved.

Next: V2 — Validation, Error Handling & Edit Expense.

Building Process Mind: A Deterministic Operating System Algorithm Simulator

Tue, 22 Sep 2026 11:29:23 +0000

I built Process Mind because I wanted a better way to practice Operating System algorithms.

When preparing for exams, I often found myself solving the same types of scheduling, page replacement, disk scheduling, and memory allocation problems repeatedly. The problem wasn't finding explanations of these algorithms. There are plenty of them.

The problem was verification.

For a manually solved problem, it is easy to make a small mistake somewhere in the calculation and only realize it much later. I wanted something where I could enter the same problem, run the algorithm, and immediately compare my result with a deterministic implementation.

That idea became Process Mind.

What is Process Mind?

Process Mind is an interactive web platform for practicing Operating System algorithms.

The current implementation covers four major areas:

CPU Scheduling — FCFS, SJF, SRTF, Priority, Preemptive Priority, Round Robin
Page Replacement — FIFO, LRU, Optimal, Second Chance, LRU Counter
Disk Scheduling — FCFS, SSTF, SCAN, C-SCAN, LOOK, C-LOOK
Memory Allocation — First Fit, Best Fit, Worst Fit, Next Fit

The goal isn't to simply display the final answer.

The application takes the user's input, validates it, runs the corresponding algorithm, and produces structured results such as calculated metrics, process details, Gantt blocks, and execution steps.

The basic flow is:

User Input
    ↓
Validation
    ↓
Algorithm
    ↓
Structured Result
    ↓
Metrics + Gantt + Process Details + Execution Steps
    ↓
UI

This separation became one of the most important design decisions in the project.

The Core Idea: Deterministic Results

There are already many tools that can explain Operating System concepts using AI or generate solutions dynamically.

I wanted Process Mind to solve a different problem.

If I enter a problem, I should get the same result every time.

For algorithm practice, determinism is useful. The application isn't trying to interpret what I meant or generate a plausible explanation. The algorithm implementation processes the input according to its defined rules.

That makes it useful for checking manually solved questions.

For example, with a CPU scheduling problem, Process Mind can calculate:

Process	Arrival	Burst	Completion	Turnaround	Waiting	Response
P1	0	7	7	7	0	0
P2	1	1	8	7	6	6
P3	2	7	15	13	6	6

It can also calculate average turnaround, waiting, and response times and represent execution using a Gantt chart.

The exact numbers depend on the input, but the important part is that the result comes directly from the algorithm.

The Difficult Part Wasn't Writing the Algorithms

Implementing FCFS or SJF isn't particularly difficult once the algorithm is understood.

The harder question was:

What information should the algorithm return?

Initially, it would have been easy to return something like:

completionTime
waitingTime
turnaroundTime

But that isn't enough for an educational tool.

If the purpose is practice and verification, users may also want to understand why a process was selected.

So the result structure evolved to contain more information:

ScheduledResult
├── processes
├── metrics
├── blocks
└── steps

The steps data became particularly useful.

Each execution step can contain information such as:

current time
ready processes
selected process
waiting queue
processes that arrived during execution
queue after execution
execution window
whether the CPU was idle
reason for selecting the process

This allows the UI to show not only what happened, but also some of the state behind the decision.

Handling Preemptive Scheduling

Preemptive algorithms introduced another layer of complexity.

For algorithms such as SRTF and Preemptive Priority Scheduling, a process can be interrupted when another process becomes eligible.

Instead of treating a process as simply "running" or "finished", the implementation needs to maintain its remaining execution time.

For example:

Process
├── arrivalTime
├── burstTime
└── remainingTime

At each relevant point, the algorithm can determine which process should run based on the current state.

Round Robin has a different challenge because execution is controlled by a time quantum. Processes that don't finish within their allocated quantum need to be placed back into the ready queue.

These differences meant that I couldn't force every scheduling algorithm into exactly the same internal implementation.

Instead, I kept the implementations independent while giving them a consistent output structure.

That gave me a useful balance:

different algorithms internally, consistent results externally.

Validation Matters More Than It Looks

Since users can enter arbitrary values, validation is an important part of the application.

I'm using React Hook Form with Zod for form handling and validation.

Inputs such as arrival time, burst time, priority, and quantum have appropriate constraints. Duplicate process IDs are also rejected.

Random input generation is included as well.

Instead of manually creating a new set of processes every time, users can generate random inputs and immediately practice with them.

This fits the original reason I started building the project: generate a problem, solve it yourself, and verify the result.

Building the Interface Around the Algorithm

One thing I learned while building Process Mind is that an algorithm implementation and an educational interface are two different problems.

The algorithm knows what happened.

The UI needs to decide how that information should be understood by a human.

For CPU scheduling, I currently use a combination of:

input forms
result metrics
process tables
Gantt charts
expandable execution steps

The Gantt chart gives a quick overview of execution, while the execution-step section exposes more detailed information when needed.

I deliberately kept the current visualization relatively simple. The larger goal is to eventually make Process Mind feel more like a simulation, but I don't want to add visual complexity just for the sake of having animations.

What I Learned

The biggest lesson from Process Mind wasn't about Next.js or TypeScript.

It was about designing data around the problem domain.

When building a normal CRUD application, the data model is often fairly obvious.

With algorithms, it isn't.

You have to decide what intermediate state matters, what information helps explain a decision, which metrics are useful, and how that information can be represented consistently across different algorithms.

I also learned that implementing an algorithm in code forces you to understand it differently.

Writing SRTF, for example, isn't the same as memorizing that "the process with the shortest remaining time executes." You have to think about arrivals, remaining time, preemption, completion, ties, queues, and every state transition.

That was one of the reasons I wanted to build Process Mind in the first place.

What's Next?

Process Mind is still evolving.

The current focus is making the existing algorithms reliable and useful for practice rather than continuously adding features.

The longer-term direction is to make the experience more simulation-oriented, with better visualization and interaction around algorithm execution.

But the core idea remains the same:

Practice the problem yourself. Run it through the algorithm. Verify your result. Understand where the execution came from.

That's what Process Mind is trying to become—a practical bridge between studying an algorithm and actually understanding how it executes.

Try Process Mind

⚛️ Controlled vs Uncontrolled Components in React – A Deep Dive

Sat, 19 Sep 2026 19:08:29 +0000

When building forms in React, you’ll inevitably come across controlled and uncontrolled components.
At first glance, they look similar — both accept user input and manage form data.
But how they manage that data under the hood can significantly impact performance, maintainability and UX.

In this blog, let’s break down the difference, see them in action, explore real-world issues (like cursor position and undo/redo bugs), and understand when to use each.

🧠 What Are Controlled Components?

In controlled components, React state is the single source of truth.
That means every keystroke or change updates the component’s state and that state determines what’s rendered.

Example:

import { useState } from "react";

function ControlledInput() {
  const [name, setName] = useState("");

  return (
    <input
      value={name}
      onChange={(e) => setName(e.target.value)}
      placeholder="Type your name"
    />
  );
}

Here, the <input> value is fully controlled by React via the name state.
Each keystroke triggers setName(), re-rendering the component with the updated value.

✅ Pros

Easy to validate or transform input on change.
Centralized state makes debugging and unit testing easier.
Integrates seamlessly with complex UIs or form libraries (Formik, React Hook Form).

⚠️ Cons

Frequent re-renders can impact performance in large forms.
Need to carefully manage performance and input lag.
Cursor position bugs can occur with advanced state management.

🧩 What Are Uncontrolled Components?

In uncontrolled components, the DOM maintains its own state — React just references it.
You don’t handle every keystroke; instead, you access the value when needed.

Example:

import { useRef } from "react";

function UncontrolledInput() {
  const inputRef = useRef();

  const handleSubmit = () => {
    alert(`Input value: ${inputRef.current.value}`);
  };

  return (
    <>
      <input ref={inputRef} placeholder="Type your name" />
      <button onClick={handleSubmit}>Submit</button>
    </>
  );
}

✅ Pros

Better performance for simple forms.
Minimal React re-renders.
Perfect when you just need the final value.

⚠️ Cons

Harder to validate or modify values dynamically.
Not ideal when input data must always reflect application state.

⚔️ Controlled vs Uncontrolled: Key Differences

Feature	Controlled	Uncontrolled
Data Source	React State	DOM (via refs)
Performance	May re-render often	Faster for simple inputs
Validation	Easy to handle dynamically	Requires manual check
Use Case	Complex, validated forms	Simple or performance-critical inputs

⚡ Valtio & Controlled Inputs: Why Cursor Jumps Happen

When you use a state library like Valtio in a React controlled input, you might encounter this issue: you edit text in the middle of the input, but the cursor jumps to the end. This frustrates users and breaks the typing experience.

🔍 What’s going on?

By default, Valtio batches updates before triggering re-renders. The documentation states:

“By default, state mutations are batched before triggering re-render. Sometimes, we want to disable the batching.”
Because of this batching behavior, when you type and update the proxy state, multiple changes may be queued and then re-rendered in one go. During that delay, the browser loses context of the input cursor position, so after render the input’s value is applied and the cursor jumps to the end.

✅ The fix: { sync: true }

Valtio provides the option to disable batching for specific use-cases like inputs:

const snap = useSnapshot(state, { sync: true });

With sync: true, updates go through immediately rather than being deferred/batched. This keeps the input cursor where the user expects it.

⚠️ Trade-off:

Using sync: true disables batching optimizations, which can reduce render efficiency in large/complex components. Therefore:

Use sync: true only in input fields where cursor behaviour matters.
Avoid it for general state where performance is more important than instantaneous update.

🔁 Undo/Redo (Cmd+Z / Cmd+Shift+Z) in Controlled Components

Another subtle but important issue:
Undo (Cmd+Z) and Redo (Cmd+Shift+Z) might not work as expected in controlled inputs.

Why?
Because React replaces the entire value on every keystroke rather than letting the browser handle native input history.

This means the browser sometimes loses the input undo stack, especially if re-renders happen between updates.

🧪 What to do:

Test undo/redo behavior in all input fields before handing over to QA.
If using a state library or custom hooks, check whether it maintains the input history properly.
In cases where it fails and browser-native undo is critical (e.g., long text editors), consider using uncontrolled inputs or controlled wrappers that debounce updates.

🧰 Best Practices for React Forms

✅ Use controlled inputs when you need validation, dynamic control or shared state.
✅ Use uncontrolled inputs when performance and simplicity matter.
✅ For state libraries like Valtio, test cursor and undo behaviors thoroughly.
✅ Avoid unnecessary re-renders – use React.memo, useCallback or split components.
✅ Always test form UX — typing, cursor and undo/redo should feel native and fluid.

🎯 Final Thoughts

Controlled vs Uncontrolled Components seem like a small React concept, but they can deeply impact user experience, especially in complex form-heavy applications.

💡 Understanding these nuances (like cursor handling, undo/redo, and batching) helps you ship smoother, bug-free UIs that feel professional and reliable.

🚀 Whether you use plain React or libraries like Valtio, always test the real typing experience — that’s where users feel the difference.

💬 Have you ever faced cursor or undo issues in your React forms? Drop your experience or workaround below — let’s learn together! 👇

Building Before I Feel Ready

Thu, 17 Sep 2026 08:41:43 +0000

There’s a strange feeling that comes with learning technology.

You can spend hours watching tutorials, reading documentation, taking courses, and solving problems and still feel like you don't know enough to build something real.

That feeling has followed me for a while.

I'm studying Electronic and Electrical Engineering, while also learning frontend development, IoT, and embedded systems. One day I'm working with React and TypeScript. The next, I'm looking at microcontrollers, sensors, circuits, or trying to figure out why some piece of hardware isn't behaving the way I expected.

There is always something else to learn.

And that's the problem.

For a while, I kept thinking I needed to learn more before I could seriously start building.

I eventually realized that was backwards.

Maybe building is how I learn what I actually need to know.

The Trap of Always Learning

The problem with always preparing is that there is never a clear point where you are “ready.”

There is always another course to finish.

Another framework to learn.

Another concept you don't fully understand.

Another project that seems slightly beyond your current skill level.

And because there is always something else to learn, it becomes easy to confuse learning with progress.

I've fallen into that trap myself.

I'd jump between frontend development, engineering courses, IoT, programming, and different ideas I wanted to explore. I was learning, but sometimes it felt like I was constantly starting rather than actually moving forward.

That's when I started changing how I approach learning.

Instead of asking:

“What do I need to learn before I can build this?”

I started asking:

“What do I need to learn to solve the next problem?”

That small change makes building much less intimidating.

You don't need to know everything.

You need to know enough to take the next step.

Building Forces You to Learn Differently
Tutorials are useful. Courses are useful. Documentation is useful.

But building something of your own changes the learning experience completely.

When you're following a tutorial, the path is already laid out. You know what comes next, what code to write, and often what the expected result should look like.

When you're building your own project, none of that is guaranteed.

You make decisions.

You run into errors you have never seen before.

You search through documentation.

You try something that doesn't work.

You change your approach.

Then, eventually, something works.

That's where I think some of the most valuable learning happens.

For example, while working on IoT projects, I’ve had to move between hardware and software, dealing with sensors and microcontrollers on one side and interfaces and data visualization on the other.

The interesting part isn't knowing every technology beforehand.

It's figuring out how to connect the pieces.

And every problem becomes a question:

Why isn't this working?

Then you look for the answer.

That process has taught me something important:

You don't always need more preparation. Sometimes you need a problem worth solving.

I'm Still Figuring Things Out
I don't want this to sound like I suddenly figured everything out.

I haven't.

I'm still learning how to write better code, design better interfaces, understand engineering concepts more deeply, and build projects that actually work outside of a tutorial.

Some projects will fail.

Some ideas will change halfway through.

Some things I build will probably look very different a few months from now.

And I think that's okay.

I'm sharing more of what I build because I want a record of the process the messy middle- not just the polished result.

The bugs.

The things I misunderstood.

The solutions I eventually found.

The decisions that worked and the ones that didn't.

I also want to meet other people who are doing the same thing: learning by building.

Because something is motivating about seeing someone else struggle through a problem, solve it, and then share what they learned.

That's the kind of developer and engineer I want to become.

Not someone who knows everything.

Someone who keeps building, keeps learning, and knows how to figure things out.

What I'm Building Now
Right now, I'm exploring the space where software and hardware meet.

On the software side, I'm building with technologies like React and TypeScript, learning how to create interfaces that are not just functional but actually enjoyable to use.

On the hardware side, I'm experimenting with microcontrollers, sensors, and IoT projects. That means dealing with things that don't always behave exactly as expected—which is a pretty effective way to learn.

I'm also studying Electronic and Electrical Engineering, so I'm constantly discovering connections between what I learn in class and what I can actually build.

That's probably what interests me most.

A web application doesn't have to exist completely separately from the physical world.

A sensor can collect data.

A microcontroller can process it.

A backend can move it somewhere useful.

And a frontend can turn that data into something a person can actually understand and interact with.

There's a lot I still don't know about all of this.

But that's exactly why I'm building.

I want to see how far I can go by learning one problem at a time.

So, What Now?
I don't have a perfectly defined roadmap.

And honestly, I'm starting to think that's okay.

For now, I want to keep building projects, documenting what I learn, and gradually getting better at connecting the different things I'm interested in.

Some posts here will probably be about frontend development.

Others might be about IoT, embedded systems, engineering concepts, or something completely different that I happen to be exploring.

I also want to share the parts that don't usually make it into portfolios—the debugging, the mistakes, the confusion, and the small breakthroughs that make a project finally work.

Maybe someone reading this is also stuck in the “I'm not ready yet” phase.

If that's you, I'm learning the same lesson myself:

You don't have to wait until you know everything.

Start with what you know.

Build something.

When you hit a problem, learn what you need to solve it.

Then build again.

That's what I'm going to do.

Build before I'm ready. Learn along the way. And keep going.

I'm Just Getting Started

This is my first post on DEV.to, and I think it should start here.

I'm not writing because I have everything figured out. I'm writing because I want to document the process of figuring things out.

I'll be sharing projects, experiments, lessons, mistakes, and whatever interesting problems I run into along the way.

If you're also learning to code, studying engineering, building projects, or trying to figure out how all these pieces fit together, maybe we can learn from each other.

For now, I'm going to keep building.

One project. One problem. One lesson at a time.

From Pro Disc Golf to Code: My Journey to Become a Full-Stack Developer

Thu, 10 Sep 2026 17:47:47 +0000

A year ago I was walking new construction homes as a field manager. I managed the installation of tile wood and carpet in new construction homes. It’s served my family and I well, and put me in situations of self growth I would have never gotten otherwise. But I hit a wall and upward mobility was stagnant. Before I was a field manager I was a professional disc golfer. It was always an adventure, I got to tour the country playing tournaments and teaching clinics. That era instilled in me a deep understanding of planning, discipline, and the power of creating systems to excel.

Current day… I am obsessed with coding. My mind is always buzzing with what I am currently learning, and what technical puzzle I am solving at the time. This passion ignited on a whim last year. I was sent a link to web development coding bootcamp from a family friend. In a whirlwind I called my amazingly supportive wife, and within 20 minutes I was enrolled in the bootcamp. Class started that same day. I had a buzzing in my body, that had me excited and scared all at the same time.

The challenges, the creativity, and the complex problem-solving drove me to fall deep into coding. This post marks the beginning of me sharing my journey. From fairway to construction site to becoming a full stack developer.

Graduating bootcamp last June, the pressure to secure a job intensified with our first child due in February. Despite relentless effort, not a single interview materialized between June and August. Providing for my family meant "biting the bullet" and returning to construction. It felt like taking a quadruple bogey on the tournament's final hole, but just like in disc golf, mental resilience became key. I pivoted. I recognized my skills weren't "up to snuff," especially with AI raising the industry bar. My love for coding made the decision clear: Rise and grind.

That "quadruple bogey" taught me not to let one bad hole ruin the entire round. I went back into the lab and re-evaluated my coding habits and systems, realizing there was immense room for improvement. The "get rich quick" mentality wasn't working. My focus shifted to a long-term, sustainable journey of growth.

One year into this revised plan, I'm already seeing progress. I'm currently interning, building the syllabus website for the very bootcamp I attended – a full-circle moment. This valuable experience, coupled with freelance work and my dedicated side project, is where I'm gaining real-world skills. My current side project, a Disc Golf Course and Round Tracker, directly reinforces my internship learnings in PHP and SQL, allowing me to immediately apply and practice what I'm currently using.

While PHP and SQL aren't my primary languages, this hands-on experience has been truly eye-opening, revealing just how much React streamlines development under the hood. Building reusable OOP components in PHP has definitely made me itch to return to React's ecosystem! Once this internship concludes, my focus shifts to an even bigger project I'm eager to tackle: a MERN stack application.

The road from professional disc golf and construction management to becoming a full-stack developer is proving to be a true test of grit and adaptability. It's a journey I'm embracing fully, learning new languages and paradigms with every step. I'm committed to building a solid portfolio and making this career transition a success. Through this blog, I aim to share the raw, unfiltered experience the “aces” and the "bogeys" if you will. I hope to connect with others on a similar path. Join me as I continue to build, learn, and grow in the world of web development.

How Online Assessments Help Students Identify Their Learning Gaps

Thu, 10 Sep 2026 11:02:12 +0000

You study for hours, walk into the exam feeling ready and then just blank out on questions you swear you knew, it happens to basically every student at some point, honestly. Usually it's not that you didn't study enough. It's that you studied the wrong things or you had gaps you never even knew were sitting there.

This is one of the biggest problems with how most students prepare, if you think about it. They read, they revise, they feel like they've got it but knowing something while reading calmly at home is not the same as pulling that answer out under exam pressure. Most students only find this out the hard way, mid exam, when there's nothing left they can do about it.

Been through this yourself? Or maybe you're a parent watching your kid go through the same thing over and over. Looking into the best platform for online courses with mock tests and assessments could genuinely change how prep goes from here.

Let's get into why assessments matter this much and how they catch gaps that plain studying just misses.

Why Just Studying Doesn't Show Your Weak Spots

Reading and revising feels productive, no doubt. You go through your notes, highlight the important bits, feel like real progress is happening but this kind of studying doesn't actually test whether you can use what you've learned under real conditions.

There's a big difference between recognising an answer when you see it and actually pulling it out of memory during a timed test. Students mix these two up all the time, thinking they're ready when they're really not. This gap only shows up once there's an actual test involved, not during casual revision on a Sunday afternoon.

Another thing, students usually don't know which topics they're actually weak in until they get tested on them directly. You might feel totally solid in a chapter because it made sense while studying. Then a question comes at it from a slightly different angle, and suddenly it's not so clear anymore.

This is exactly the kind of blind spot regular assessments catch. A good best platform for online courses with mock tests and assessments means you're not guessing where you stand anymore. You actually find out through real practice, way before the real exam catches you off guard.

How Mock Tests Show What You Actually Know

Mock tests work differently from just studying. They put you in something close to the real exam environment- time pressure, unfamiliar phrasing, needing to recall stuff fast without flipping back to your notes, all of it mirrors exam day pretty closely.

Taking a mock test isn't just about checking if you know the material. It's about checking if you can actually access that knowledge when there's pressure involved. So many students find out during mock tests that they freeze up, or completely blank on things they knew perfectly well while studying at home. That's genuinely useful information, and you only get it through real testing.

Mock tests also show patterns in your mistakes that you'd otherwise never notice. Maybe you keep messing up a certain type of question, not because you don't get the concept but because you keep misreading how it's framed. This kind of pattern is nearly impossible to catch without taking several tests and actually going back to review them properly.

This is really where the value lies in using the best platform for online courses with mock tests and assessments on a regular basis, not just the one time right before your exam. Repeated testing shows patterns over time, patterns a single test just can't reveal on its own.

Why Regular Testing Beats One Test

A lot of students only sit for a mock test close to their exam date, treating it as some final check rather than a tool they use throughout. This actually limits how useful it can be, because by then there's barely any time left to fix whatever comes up.

Regular assessments spread through your prep work completely differently. Instead of discovering weak spots a week before your exam, you find them out weeks, sometimes months, earlier. That gives you real time to actually work on them instead of panicking at the last minute.

This kind of approach also lets you track your own improvement. Taking assessments regularly shows you whether you're genuinely getting better in your weak areas, or if the same mistakes just keep popping up again and again. You simply can't track this with one test taken right before the exam.

Good platforms understand this, it is exactly why the best platform for online courses with mock tests and assessments usually has regular testing built right into the course, not some token test tacked on at the end where there's nothing left to do with the results anyway.

The Confidence Some People Don't Talk About Enough

There's another side to this that doesn't get discussed much. Regular assessments don't just point out where you're weak, they build real confidence in the areas where you're actually strong too and this matters way more than people give it credit for when it comes to exam day performance.

A big chunk of exam anxiety just comes from uncertainty, not really knowing where you stand.

Students who've never properly tested themselves walk in unsure if they're ready, and that uncertainty alone creates stress that hurts performance, even in the parts they were actually well prepared for.
Students who've taken regular assessments though, they walk in with a much clearer picture. They know what they're good at, they've worked on what they weren't, less unknown territory to be nervous about. That kind of confidence, built through real practice instead of just hoping for the best, genuinely changes how exam day goes.

This is another big reason the best platform for online courses with mock tests and assessments matters so much, not just for catching gaps but for building the kind of confidence that only comes from actually knowing where you stand.

What To Actually Check In A Good Assessment Platform

If you're picking a platform for this, there's a few things worth checking properly first. Make sure the mock tests genuinely match the real exam pattern, not some generic set of questions that has nothing to do with what you'll actually face on exam day.

Check if the platform gives you detailed feedback after each test too, not just a score sitting there with no explanation. A number alone doesn't really tell you much, what helps is knowing exactly which topics or question types are tripping you up, so you know what to fix next.

Look for platforms that offer regular assessments spread across the whole course, not just occasional ones here and there. Like mentioned earlier, consistent testing over time reveals patterns that a one off test just can't show you.

And check if there's actual support to help you work on the gaps once you've found them. Finding your weak spots is honestly only half the battle, having proper guidance or resources to fix them is what makes this whole process genuinely useful, not just informative on paper.

Final Thoughts: Turning Weak Spots Into Strong Ones

At the end of the day, the whole point of finding your learning gaps is to actually fix them, not just know they're there. Assessments show you exactly where to put your energy, instead of spreading effort evenly across stuff you're already good at and stuff you're genuinely struggling with.
Students who use assessments properly through their whole preparation, not just once at the very end, usually walk into exams with a much clearer sense of how ready they actually are. They've already faced their weak spots during practice, worked through them, and built confidence through repeated testing rather than just crossing their fingers.

If you're serious about finding your real learning gaps and actually fixing them before the real exam shows up, ItLearn by Imbibe Tech is genuinely one of the best platform for online courses with mock tests and assessments out there right now. It gives you regular testing, detailed feedback, and real guidance to work on exactly what's holding your score back. Don't wait for exam day to figure out where you're weak.

Get started with ItLearn by us today and use the best platform for online courses with mock tests and assessments to prepare the right way, right from the start.

How I Survived the Silent AI Upgrades (And Shifted My Workflow)

Wed, 09 Sep 2026 13:24:29 +0000

The Day the Premium Quotas Melted

We’ve all seen the massive marketing headlines celebrating multi-million token context windows. So when I scored access to the Google AI Pro student tier, I figured I was completely set.

My journey into the anatomy of a prompt didn’t happen overnight; it started a while back when I was experimenting with visual generation in Adobe Firefly. By August of last year, I got deep into language models, eventually using them to power through my EBAC programming course and moving my coding workflows directly into Antigravity IDE. Over nearly a year of continuous, everyday use, I learned exactly how these systems tick. As an aspiring developer, I optimized my prompts, mapped out constraints, and treated the LLM like a highly predictable engine to accelerate my learning.

Naturally, I put my established setup to the test. I uploaded my personal documentation, technical archives, and coding references into the newly rebranded Gemini Notebook (formerly NotebookLM), running Flash Extended to handle the retrieval. I wasn't even running heavy Pro-level operations—just a routine pass to extract milestones and start drafting a profile.

Then, I asked a few formatting questions, checked my usage dashboard, and watched in pure disbelief as 50% of my rolling 5-hour compute quota completely evaporated in a matter of minutes.

I hadn't changed my source files. I hadn't switched models mid-session. But the architectural ground shifted anyway. Here is exactly what is happening under the hood with these silent AI infrastructure rollouts, and how a junior dev's workflow had to change overnight to survive the token crunch.

1. The Background Agent Tax

We used to think of Large Language Models as linguistic calculators—they predicted the next most probable word based on pattern matching.

But with recent infrastructure upgrades, the underlying architecture has evolved into something much more complex. When you ask a modern AI assistant a complex analytical question over your documents, it doesn't just read the text anymore. The system silently provisions a secure cloud computer, writes a custom Python script to parse your sources, executes it, and formats the output.

Because the Gemini ecosystem now shares parts of the same agentic code-execution harness used by Antigravity IDE, it treats your documents like an active environment. While this makes the AI incredibly precise and practically eliminates linguistic math hallucinations, it comes with a massive compute surcharge. Every background execution loop, sandboxed environment state, and data variable has to be held in the active context window. You aren't just paying for the words you read; you are paying the operational runtime of a background software engineer.

2. Aggressive Context Slicing

To prevent web interfaces from lagging under the weight of these massive agentic loops, consumer applications are quietly implementing context slicing and extreme text compression behind the scenes.

Once your conversational history crosses a certain threshold or accumulates too many background code-execution logs, the interface stops passing the entire thread to the model. Instead, it relies on silent retrieval chunks. This is why an AI you’ve been working with seamlessly for an hour will suddenly "forget" a critical formatting rule or a core naming convention you established in prompt #2.

My New AI Survival Blueprint: Ecosystem Hopping

To keep my workflows efficient and stop burning through my daily student compute caps by noon, I’ve completely restructured how I interact with LLMs. The secret? You have to jump across different Google products strategically to keep your tokens alive.

Separating Extraction from Iteration: I no longer do creative drafting or iterative formatting inside data-dense notebooks. I use the notebook once to let the agent parse the files and extract a clean, structured text baseline or chronological milestone list.
The "Clear Slate" Migration: Once I have that raw text block, I copy it out, close the heavy workspace entirely, and paste it into a completely fresh, standard chat window. By decoupling the heavy data-parsing engine from the creative-writing layer, my compute footprint drops to near zero.
Graduating to Developer Environments: For complex programming or tracking intricate data structures where memory loss is a project-killer, I step outside the consumer web wrappers and jump into Google AI Studio. Getting raw model access gives you deterministic control over your context window and absolute visibility over your exact token count, completely bypassing the aggressive background agent surcharges.

The Takeaway: AI isn't just getting bigger; it's getting hungrier. Even if you've spent a year mastering the tool, hold premium tier access, and use it to power through coding bootcamps, if you don't actively manage your context architecture, the infrastructure will manage it for you—usually at the expense of your active memory. As developers, our job isn't just to write code; it's to understand the systems we build upon. And right now, navigating the AI layer demands a completely new style of resource management.

The power of mental models for developers

Wed, 09 Sep 2026 11:26:43 +0000

Down the memory lane

Some developers don’t understand memory.
They understand new, delete, or garbage collection. And again — that’s just the surface.

Memory is not a flat, uniform space.
It’s a hierarchy:
• registers
• multiple levels of cache
• RAM
• virtual memory managed by the OS
Each layer has different latency and behavior.

But we usually learn memory management like this:
“allocate object → use it → free it”
So we assume: as long as memory is “managed”, everything is fine.
It’s not.

Performance is often dominated by:
• cache locality
• allocation patterns
• fragmentation
• allocator contention

That’s why two identical algorithms can have wildly different performance
depending on how data is laid out in memory.

Using smart pointers doesn’t mean you understand memory. It means you’ve delegated part of the problem. Which is fine — until it isn’t.

If you care about performance, you need to understand:

how data moves,
how it’s cached,
and how it’s allocated.

Because in the end:
It’s not about what your code does.
It’s about how it lives in memory.

Building blocks

Data types are one of the most misunderstood fundamentals.
Because we don’t really learn what they are.

We learn their names: int, float, bool - feel like simple building blocks.
But underneath, they are:
• bit patterns
• rules of interpretation
• operations defined over those bits
Without that model, decisions become guesswork.

Like using signed integers for sizes.
A size is a count. It cannot be negative.

But if your type allows negative values, you’ve already introduced invalid states into your system.
This leads to subtle bugs:
• overflow issues
• signed/unsigned comparison traps
• edge cases that “should never happen” — but do

The deeper issue is this:
A type is not a label. It’s a constraint on reality.

If you don’t understand:
• binary representation
• overflow behavior
• how arithmetic actually works at the hardware level
then you’re not choosing types. You’re guessing.

And sometimes guessing is enough.
Until it isn’t.

We teach developers what to write.
We rarely teach them what it means.

Concurrency

Some developers don’t learn concurrency. They learn async/await or whatever concurrency utilities their favorite language or framework provides. And those are not the same thing.

Threads are not a language feature. They exist at the OS level, run on physical CPU cores, and compete for shared memory and cache.

But many of us first encounter concurrency through: Python, C++, Java, or some framework API.
So our mental model becomes: “this is how concurrency works.”
It’s not.
It’s just how one runtime exposes it.

That’s why things feel unpredictable:
• “Why do I still get race conditions?”
• “Why is my async code slower than sync?”
• “Why doesn’t this scale across cores?”
Because underneath:
• the OS scheduler decides who runs
• context switching is not free
• cores share memory with non-uniform latency
• caches can invalidate each other

If you don’t understand that layer, you’re not really reasoning about concurrency.
You’re just using it.

To be clear — that’s fine at the beginning.
But the moment you care about performance or correctness under load,
you have to go down the stack.

Hardware → OS → runtime → language.
Not the other way around.

Otherwise you’re not solving concurrency problems.
You’re operating an API.

Abstractions are just tools

In previous chapters I talked about:
• concurrency
• memory
• data types

At first glance, these look like different topics.
They’re not.

They all share the same root problem:
We learn abstractions… without understanding what they abstract.

We learn:
• async/await instead of how threads are scheduled
• new/delete instead of how memory behaves
• int/float instead of how data is represented

So our mental model becomes: “this is how the system works”
When in reality: “this is how one layer exposes it”

And most of the time, that’s enough.
Until it isn’t.

The cracks appear when:
• performance matters
• systems scale
• bugs become non-deterministic
• behavior stops matching intuition

That’s when abstraction stops helping and starts hiding the problem.

This doesn’t mean everyone must become a hardware engineer.
But it does mean:
If you want to reason about systems, you need to understand the layers below them.

A simple rule that helped me:
When something feels “weird” or unpredictable — you’re probably missing a layer in your mental model.

Go one level deeper:
hardware → OS → runtime → language.
That’s usually where the answer is.

Abstractions are tools.
But understanding is leverage.

Mental model

A fair question may come up:
“How do I actually learn all these lower layers without going down a 5-year rabbit hole?”

Short answer:
You don’t need to learn everything. You need to learn just enough to build a mental model.

Here’s what actually works.

Learn one layer below your current work
If you’re writing application code → learn runtime behavior
If you’re using runtime features → learn OS basics
If you’re already there → peek into hardware
Don’t jump straight into CPU manuals. Go one step down.
Learn through problems, not theory
Don’t start with textbooks.
Start with questions like:
• “Why is this slower than expected?”
• “Why does this break under load?”
• “Why does this behave differently on another machine?”
Then dig until you hit the real cause. That’s where learning sticks.
Build small, focused experiments
You don’t need big projects.
Try things like:
• write a tiny thread pool
• measure cache effects with different data layouts
• intentionally create a race condition and observe it
• compare contiguous vs scattered allocations
You’ll learn more from one experiment than from hours of passive reading.
Use tools that show reality
Start simple:
• profilers (CPU, memory)
• timing measurements
• system monitors
Look at what the system is actually doing — not what you think it’s doing.
Accept partial understanding
You don’t need to master everything.
If you walk away knowing:
• caches exist and affect performance
• threads are scheduled, not “run” by your code
• memory is not uniform
you’re already ahead of most developers.
Go deeper only when it pays off
Not every problem needs low-level knowledge.
But when something feels:
• slow
• unpredictable
• “magical”
that’s your signal to go down a layer.

You don’t need to become a systems expert.
But you do need to know when the abstraction stops being enough.
That’s the real skill.

The Microsoft Learn Roadmap I Would Give a First-Year CS Student

Tue, 08 Sep 2026 16:37:09 +0000

When I talk to first-year computer science students, I notice the same pattern almost every time.

Someone has a playlist for Python.

Someone else says you should learn C++ first.

A YouTuber recommends learning cloud.

Another says AI is the future.

Then there are certifications, GitHub projects, roadmaps, coding platforms, hackathons, and dozens of tabs sitting open in the browser.
The result?

A lot of students spend more time planning what to learn than actually learning.

I think this happens because we're exposed to an endless amount of technology content from day one. Every topic sounds important. Every roadmap looks urgent. Every certification seems like something we should start immediately.

The mistake isn't curiosity.

The mistake is trying to learn everything at once.
Over time, I've become convinced that structured learning beats collecting tutorials.

A hundred bookmarked videos don't automatically create progress. A clear sequence of skills usually does.

If I were advising a first-year CS student today, this is the roadmap I would suggest. It's practical, realistic, and designed to fit alongside university studies instead of competing with them.

Stage 1: Build Programming Fundamentals First

This stage is not exciting.
That's exactly why it's important.
Before thinking about cloud platforms, machine learning models, cybersecurity tools, or DevOps pipelines, you need to become comfortable with basic programming concepts.
Focus on things like:

Variables
Data types
Conditions
Loops
Functions
Arrays and data structures
Problem solving
Basic debugging

The specific language matters less than most people think.

Your university may start with C++, Java, Python, or C#. That's fine.

What matters is understanding how programs work.

I've seen students jump straight into trendy topics and then struggle because basic programming logic wasn't solid. When that foundation is weak, every advanced topic feels harder than it should.

Microsoft Learn is useful here because many learning paths are structured, not random collections of videos.

Instead of asking, "What should I learn next?", the path already guides you through the next concept.

Resource:
https://learn.microsoft.com/?wt.mc_id=studentamb_496381

At this stage, don't worry about building impressive projects.
Learn how to write code that works.

Stage 2: Learn Git and the Developer Workflow

This is one of the most overlooked skills among beginners.

Many students spend months learning programming but still don't know how professional developers manage code.

Learning Git early pays off much faster than most students expect.

Get comfortable with:

Repositories
Commits
Branches
Pull requests
Version control basics
GitHub collaboration

The goal isn't becoming a Git expert.

The goal is making Git part of your normal workflow.

Imagine you're working on an assignment.

Instead of keeping files named:

project_final
project_final2
project_final_actual
project_final_latest_final

You use Git commits to track changes properly.
That's a small shift, but it mirrors how software is built in real environments.

The earlier you develop these habits, the easier team projects, hackathons, internships, and open-source contributions become.

Stage 3: Choose One Direction Instead of Chasing Everything

This is where many students get stuck.

They try to learn:

Cloud
AI
Data Science
Cybersecurity
DevOps
Mobile Development
Web Development

All at the same time.

I wouldn't do that.

After building programming fundamentals, pick one direction that genuinely interests you.
Not forever.
Just for the next few months.

For example:

Cloud

Learn:

Cloud fundamentals
Virtual machines
Storage
Networking concepts
Basic Azure services

AI

Learn:

Python
Data handling
Machine learning fundamentals
Generative AI concepts
Model evaluation basics

Data

Learn:

SQL
Data visualization
Data analysis
Databases

DevOps

Learn:

Linux basics
CI/CD concepts
Containers
Automation

Security

Learn:

Security fundamentals
Identity concepts
Threat awareness
Security best practices

Application Development

Learn:

Frontend frameworks
Backend basics
APIs
Databases

The goal isn't specialization.

The goal is reducing noise.

Students often think choosing one path means missing out on everything else.

Actually, it usually helps you learn faster because your attention isn't split across six different roadmaps.

Microsoft Learn has dedicated learning paths for all of these areas, making exploration much easier without constantly searching for the next resource.

Stage 4: Build a Small Project

This is the stage that separates learning from consuming content.

At some point, tutorials stop helping.

The only way forward is building something.

The project does not need to be impressive.

In fact, I would intentionally keep it small.

Examples:

A student expense tracker
A task management application
A weather dashboard
A simple chatbot
A portfolio website
A basic inventory system
A data analysis dashboard

The purpose of the project isn't showing off.

The purpose is discovering what you don't know yet.

Projects expose gaps that tutorials hide.

You suddenly realize:

Your Git workflow needs improvement.
Your debugging skills need work.
Your database knowledge is incomplete.
Your API integration doesn't work properly.

That's normal.

Those lessons are valuable because they're connected to real problems.

University courses often provide theoretical foundations. Personal projects provide practical context.

The combination of both is powerful.

Stage 5: Validate Practical Skills

A lot of students ask me when they should think about certifications and credentials.

My answer is usually:

Not first.

Not second.

Definitely not before learning the fundamentals.

Once you've built some practical skills and completed projects, then credentials start making more sense.

One thing I like about Microsoft Learn is that it doesn't only focus on reading content.

Students can also explore:

Role-based learning paths
Applied Skills
Technical credentials
Hands-on exercises

Applied Skills are particularly interesting because they focus on demonstrating practical abilities in specific scenarios rather than simply collecting study material.
At this point, credentials become evidence of learning rather than substitutes for learning.
That's an important difference.

How I Would Use Microsoft Learn Alongside University

I would not replace university coursework with online learning.

I would combine them.

For example:

If you're studying databases this semester, reinforce those concepts with database-related learning paths.

If you're learning networking concepts in class, explore cloud networking fundamentals afterward.

If you're working on a software engineering project, use GitHub and developer workflow resources to support that work.

The best approach isn't separating university learning from industry learning.

It's connecting them.

When both reinforce each other, concepts tend to stick much better.

What I Would NOT Do

If I were starting again as a first-year CS student, here are several things I would actively avoid.

I would not collect endless roadmaps.

Eventually, you need one roadmap and consistent effort.

I would not start five certifications at the same time.

Finishing one meaningful learning path is usually better than partially completing several.

I would not chase every technology trend.

New tools appear constantly.

Foundational skills remain valuable much longer.

I would not spend months only watching tutorials.

Learning requires building.

Projects expose weaknesses that passive learning cannot.

I would not compare my progress to students posting achievements online.

Everyone's learning journey is different.

Comparisons often create pressure without creating progress.

A Practical Weekly Routine

If you're currently in your first year, I would keep things simple.

Monday to Friday

Focus primarily on university coursework.
Spend 30 to 45 minutes on a Microsoft Learn learning path.
Take notes on concepts that connect to your classes.

Saturday

Work on a personal project for 2 to 3 hours.
Apply something learned during the week
.

Sunday

Review notes.
Update project progress.
Plan the next week's learning goals.

That's it.

Not six hours every day.

Not three different certifications simultaneously.

Not twenty browser tabs full of unfinished tutorials.

Just consistent progress.

The biggest lesson I've learned is that successful students aren't necessarily the ones learning the most technologies. They're often the ones following a structured path long enough to build real skills.

If you're feeling overwhelmed by the number of technologies out there, don't try to learn everything this semester.

Pick a foundation. Choose a direction. Build something small. Stay consistent.

And if you're looking for a structured place to explore technical topics, Microsoft Learn is a resource worth keeping in your toolkit:

https://learn.microsoft.com/?wt.mc_id=studentamb_496381

If you're currently a CS student, what's the one technology area you're focusing on this semester, and why?

From Isolation to AURA: Finding Safe Developer Spaces

Mon, 07 Sep 2026 12:00:45 +0000

When I transitioned into software development through online courses, I was operating in a complete vacuum. With no tech professionals in my immediate circle, every obstacle felt magnified. In this article, I reflect on how different platform dynamics — from personal branding showcases to competitive sandboxes — directly impacted my growth as an engineer, and how finding the right low-noise space shifted my perspective.

Reading technical documentation or complex articles back then often pushed me into deeper isolation rather than helping. Looking back now, I rationally understand that "there are no dumb questions". But when you are stuck in a vacuum, without peers who share the same path, those doubts don't feel like logical problems — they feel like overwhelming personal failures. I was terrified to ask my course mentors basic questions, relying almost entirely on AI to navigate forward by trial and error.

The LinkedIn Showcase & The Learning Curve

When I joined LinkedIn, reading the feed was intimidating. Everyone appeared wildly successful, with complex titles and flawless career trajectories.

Of course, this is my purely personal perspective — perhaps due to my relative newcomer status in tech, I simply haven't fully mastered the rules of this game yet. In reality, behind the polished storefront, there are undoubtedly many genuine success stories. But in a space heavily driven by personal branding and character limits, I felt the constant pressure of a "numbers game." Fortunately, even within that high-noise environment, I managed to separate the wheat from the chaff and connected with a few incredible people who took the time to review my code and collaborate.

DEV.to: The Competitive Sandbox

Later, I explored DEV.to. I genuinely respect DEV.to for its platform structure — especially the hackathons and writing contests. It's a fantastic space where developers can test their skills, build projects for themselves, win real prizes, and get discovered.

However, while DEV.to offered the excitement of competition, the lack of direct messaging meant that meaningful, two-way technical discussions often got lost under algorithm-driven feeds and high-volume tutorials.

CoderLegion: Finding a Low-Noise Dynamic

For my current workflow, I realized I needed a hybrid dynamic: the ability to publish deep technical breakdowns alongside a low-noise, direct way to debate architecture with peers without formal barriers.

This isn't to say one platform is universally "better" than another, but this quieter, human-centric approach (which I found in spaces like CoderLegion) simply fit my personal learning and engineering style much better. Stepping out of the "silent observer" role in a low-noise space gave me the confidence to refine my ideas. It was through these direct, unhurried discussions that the concept behind my AURA (AI User Risk Assessment) framework transformed from a rough hypothesis into a structured, production-ready specification.

Why Safe Spaces Matter: A Lesson from Banking

This realization didn't come out of nowhere. Before software engineering, I worked at ProCredit Bank — one of the most successful financial institutions in Moldova, where many alumni now hold leading positions across the country's financial sector.

One practice stuck with me: our unfiltered brainstorming sessions (or what we informally called "throwing ideas at the fan"). We had dedicated spaces where anyone could voice any raw, unrefined, or seemingly "silly" idea without fear of judgment. Because the fear of looking incompetent was removed, those sessions consistently yielded our strongest architectural decisions.

Software engineering requires that same psychological safety. Great code isn't written in fear; it emerges through open dialogue.

Conclusion

There is no single "right" platform for everyone. Some thrive in the fast-paced visibility of LinkedIn; others find their rhythm in DEV.to hackathons.

My advice to fellow developers — especially those feeling isolated — is simply to find the space where you don't have to focus so much on numbers, and where you feel safe enough to ask questions, debate architecture, and turn raw ideas into real engineering. For me, that space became right here on CoderLegion (so if you're reading this on the platform, consider yourself in good company!))), and it made all the difference in my journey.

💬 Where have you found your safe space for deep engineering discussions without the noise? I’d love to hear your thoughts and experience in the comments!

Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step

Fri, 04 Sep 2026 16:08:26 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who is surprised by how cold it is in the Netherlands even though it’s still summer. 😸

Have you used DSA View View already? 👀👀

https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view--djo

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous articles, we looked at problems like:

Two Sum
Binary Search
Bubble Sort
Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree

https://dev.to/nyaomaru/is-learning-dsa-boring-lets-use-dsa-view-view-two-sum-binary-search-and-bubble-sort-374o

https://dev.to/nyaomaru/learn-valid-parentheses-reverse-linked-list-and-tree-max-depth-with-step-by-step-visualization-in-3o09

This time, let's try three more classic problems:

Number of Islands
Invert Binary Tree
Course Schedule

These three problems introduce some very useful ways of thinking:

Explore connected things
Transform a tree with recursion
Resolve dependencies in the right order

The implementations are not huge.

But the runtime can become surprisingly difficult to hold in our heads.

So let's view what actually happens. 👀

Let's learn together! 😸

🏝️ Number of Islands

Let's start with Number of Islands.

Suppose we have this grid:

1 means land. 🏝️

0 means water. 🌊

Land connected vertically or horizontally belongs to the same island.

So how many islands are there?

Let's look at the first group.

1 1
1

These cells are connected.

So they form one island.

On the right side

    1
  1 1

Those cells are also connected.

So the answer is 2.

Nice! 🏝️🏝️

But how do we make the code understand that several 1s belong to the same island?

Find One Land, Then Explore All Connected Land

The basic idea is

When we find a new 1, count one island and visit all land connected to it.

Let's use this implementation.

function numIslands(grid: string[][]): number {
  let islands = 0;

  const visit = (row: number, col: number): void => {
    if (row < 0 || col < 0) return;
    if (row >= grid.length || col >= grid[row].length) return;
    if (grid[row][col] !== "1") return;

    grid[row][col] = "0";
    visit(row + 1, col);
    visit(row - 1, col);
    visit(row, col + 1);
    visit(row, col - 1);
  };

  for (let row = 0; row < grid.length; row++) {
    for (let col = 0; col < grid[row].length; col++) {
      if (grid[row][col] === "1") {
        islands++;
        visit(row, col);
      }
    }
  }

  return islands;
}

There are two important parts.

First, we scan the grid

for (let row = 0; row < grid.length; row++) {
  for (let col = 0; col < grid[row].length; col++) {

Then, when we find land

if (grid[row][col] === "1") {
  islands++;
  visit(row, col);
}

We count a new island.

But then visit() does something important.

It removes all land connected to that island from future consideration.

Why Do We Change `1` to `0`?

Inside visit() we have

grid[row][col] = "0";

At first, changing land into water looks a little strange. 😿

But here, 0 really means

We already visited this land.

Let's follow a tiny example.

1 1
1 0

We start at the top-left. And we found land! So

islands = 1

Then

visit(0, 0);

Inside visit(), we mark it as visited.

0 1
1 0

Then we visit the four directions

down
up
right
left

Going down finds another 1.

0 1
1 0
↑

So we visit it too.

0 1
0 0

Going right from the original cell also finds land.

Visit it.

0 0
0 0

Now the whole connected island has disappeared from our search.

When the outer loops continue, there is no 1 left in that island to count again.

That's the key idea.

Count once, then mark the whole connected area as visited.

Why Four Recursive Calls?

We use

visit(row + 1, col);
visit(row - 1, col);
visit(row, col + 1);
visit(row, col - 1);

That means

        up
         ↑
left ← current → right
         ↓
        down

Each visited cell asks

Is there more land next to me?

And every newly discovered land cell asks the same question again.

This continues until we reach:

water
outside the grid
land we already visited

Those cases stop the recursion.

The Base Cases

These lines protect us

if (row < 0 || col < 0) return;
if (row >= grid.length || col >= grid[row].length) return;
if (grid[row][col] !== "1") return;

So,

If we walk outside the grid, stop.
If we reach water, stop.
If we reach a cell we already changed to 0, stop.

Otherwise, continue exploring.

Let's Follow Two Islands

Consider

1 1 0
0 0 1
0 1 1

The scan begins at the top-left.

Found land.

islands = 1

visit() removes everything connected to it.

0 0 0
0 0 1
0 1 1

The loops continue.

Eventually we reach

Another 1.

islands = 2

And visit() explores that entire connected area.

0 0 0
0 0 0
0 0 0

Done!

2 islands

🎉

Complexity

Every cell is processed at most a small number of times.

If the grid has m rows and n columns

Time:  O(m × n)

In the worst case, the recursive call stack may grow with the number of land cells.

Space: O(m × n)

👀 Let's View View It

This is one of those algorithms where the final code is pretty small.

But while reading it, there are a lot of things moving at once

row
col
grid
islands
recursive calls

And then suddenly we see

grid[row][col] = "0";

Why did that cell disappear?
Which recursive call are we inside?
Which cells belong to the current island?
Where will the outer loop continue after recursion finishes?

That is a lot to simulate mentally. 😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoibnVtYmVyLW9mLWlzbGFuZHMiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

When we view it step by step, the idea becomes much more visual.

Find land
  ↓
islands++
  ↓
visit connected land
  ↓
mark it visited
  ↓
expand up / down / left / right
  ↓
return to scanning
  ↓
find next island

Instead of thinking about recursion first, I like to think about it like this

Find one island, paint the whole island away, then keep searching.

🏝️😸

🌳 Invert Binary Tree

Next, let's invert a binary tree.

Suppose we have

We want to change

Every left child becomes the right child.

Every right child becomes the left child.

Simple, right?

Well, the final implementation is also surprisingly small.

function invertTree(root: TreeNode | null): TreeNode | null {
  if (root === null) return null;

  const left = invertTree(root.left);
  const right = invertTree(root.right);

  root.left = right;
  root.right = left;

  return root;
}

That's almost suspiciously short. 👀

Go Down First

Let's use a smaller tree.

    1
   / \
  2   3

We start at node 1.

But we don't swap immediately.

First,

const left = invertTree(root.left);

So we go to node 2.

Node 2 also tries to invert its left child.

But there is no child.

if (root === null) return null;

returns null.

The same thing happens on the right side of node 2.

Now node 2 has

left = null
right = null

root.left = right;
root.right = left;

does not visibly change anything.

Node 2 returns.

Then node 1 explores its right subtree.

Node 3 also has no children, so it returns after the same process.

Only then do we come back to node 1.

Now

left = 2
right = 3

And we do

root.left = right;
root.right = left;

    1
   / \
  2   3

becomes 👇

    1
   / \
  3   2

Done! 🎉

The Important Part: The Swap Happens on the Way Back

This is what makes the recursive solution interesting.

The function first goes down.

1
↓
2
↓
null

Then it comes back.

Later it explores the other side.

1
↓
3
↓
null

And after both children have returned, the current node swaps them.

So the flow is more like

Go left
  ↓
Invert left subtree
  ↓
Go right
  ↓
Invert right subtree
  ↓
Swap the returned subtrees
  ↓
Return current node

The tree transformation is built while recursion unwinds.

A Slightly Bigger Example

Let's look at

We start at 4.

invertTree(4)

Then

invertTree(2)

Then

invertTree(1)

Node 1 returns.

Then node 3 returns.

Now node 2 has

left = 1
right = 3

Swap them.

    2
   / \
  3   1

Then recursion returns to 4.

The right subtree rooted at 7 is also processed.

Finally node 4 receives

left = inverted subtree rooted at 2
right = inverted subtree rooted at 7

and swaps them.

The final tree becomes

The interesting thing is that each node only needs to know about its own two children.

It doesn't need to understand the whole tree.

Complexity

We visit every node once.

Time: O(n)

The recursive call stack depends on the height of the tree.

Space: O(h)

For a balanced tree

O(log n)

In the worst case

O(n)

👀 Let's View View It

This is exactly where recursion can become difficult to mentally simulate.

The code says

const left = invertTree(root.left);
const right = invertTree(root.right);

Then

root.left = right;
root.right = left;

But my brain immediately starts asking:

Which root are we talking about now?
Did node 2 already swap?
Are we still going down?
Or are we coming back up?
What does left contain at this moment?

😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoiaW52ZXJ0LWJpbmFyeS10cmVlIiwibCI6InR5cGVzY3JpcHQiLCJtIjoidmVyaWZpY2F0aW9uIiwidiI6MX0

When we step through the runtime, we can separate two different movements.

The final code is short.

But the actual runtime has a rhythm 🎵

Go down
↓
Return
↓
Swap
↓
Return
↓
Swap

Once I can see that rhythm, the recursive solution feels much less magical. 🌳😸

🎓 Course Schedule

Finally, let's look at Course Schedule.

This one is a little more difficult.

Suppose we have three courses

0
1
2

And the prerequisites are

[1, 0]
[2, 1]

That means

To take course 1, finish course 0 first.
To take course 2, finish course 1 first.

So the dependency looks like

0 → 1 → 2

Can we finish all courses?

Yes.

We can take them in this order 0 → 1 → 2.

Easy.

But what if the dependencies look like this?

0 → 1
↑   ↓
└── 2

Now

0 needs 2
1 needs 0
2 needs 1

Everyone is waiting for someone else.

We can never start.

That is a cycle.

And if there is a cycle, we cannot finish all courses.

Build the Graph

Here is the implementation:

function canFinish(numCourses: number, prerequisites: number[][]): boolean {
  const graph: number[][] = Array.from({ length: numCourses }, () => []);
  const indegree: number[] = Array(numCourses).fill(0);

  for (const [course, prerequisite] of prerequisites) {
    graph[prerequisite].push(course);
    indegree[course]++;
  }

  const queue: number[] = [];
  for (let course = 0; course < numCourses; course++) {
    if (indegree[course] === 0) queue.push(course);
  }

  let completed = 0;
  for (let head = 0; head < queue.length; head++) {
    const course = queue[head];
    completed++;

    for (const next of graph[course]) {
      indegree[next]--;
      if (indegree[next] === 0) queue.push(next);
    }
  }

  return completed === numCourses;
}

There are a few moving parts here.

graph
indegree
queue
completed

This is exactly the kind of algorithm where every individual line makes sense.

but the whole thing can still feel confusing. 😿

Let's break it down.

What Is `graph`?

For

0 → 1 → 2

we want to know

After I finish this course, which courses become closer to being available?

graph[0] = [1]
graph[1] = [2]
graph[2] = []

That means

Finish 0
↓
course 1 is affected

Finish 1
↓
course 2 is affected

We build that here

graph[prerequisite].push(course);

What Is `indegree`?

indegree tells us how many prerequisites a course is still waiting for.

For

0 → 1 → 2

we have

course 0: 0 prerequisites
course 1: 1 prerequisite
course 2: 1 prerequisite

indegree = [0, 1, 1]

Course 0 is special. Because it does not need anything before it.

So we can start there immediately.

Start With Courses That Need Nothing

We build the queue

for (let course = 0; course < numCourses; course++) {
  if (indegree[course] === 0) queue.push(course);
}

For our example

indegree = [0, 1, 1]

Only course 0 has zero prerequisites.

queue = [0]

This means

Course 0 is currently available.

Finish Course 0

Take

course = 0

Then

completed++;

completed = 1

Now look at courses depending on 0.

graph[0] = [1]

Course 1 was waiting for one prerequisite.

But course 0 is now complete.

indegree[1]--;

Then

indegree[1] = 0

Now course 1 needs nothing.

So we add it to the queue.

queue = [0, 1]

Finish Course 1

course = 1

Now

completed = 2

Course 2 depends on 1.

indegree[2]: 1 → 0

Add it to the queue.

queue = [0, 1, 2]

Finish Course 2

Finally

course = 2

completed = 3

And

numCourses = 3

Therefore

completed === numCourses; // true

We can finish everything! 🎉

Why Does This Detect a Cycle?

Now let's try

0 → 1
↑   ↓
└── 2

Every course has one prerequisite.

indegree = [1, 1, 1]

We try to build the initial queue.

if (indegree[course] === 0)

But there is no course with indegree 0.

So, nothing can start.

Therefore

completed = 0

And,

0 === 3 // false

We cannot finish the courses.

Another Example

Suppose

0 → 2
1 → 2
2 → 3

Course 2 needs both 0 and 1.

indegree = [0, 0, 2, 1]

The initial queue is

queue = [0, 1]

Finish 0.

indegree[2]: 2 → 1

Course 2 is still waiting.

So don't add it yet.

Finish 1.

indegree[2]: 1 → 0

Now course 2 is ready.

queue = [0, 1, 2]

Finish 2.

indegree[3]: 1 → 0

Now

queue = [0, 1, 2, 3]

Everything can be completed.

This is the key idea

When all prerequisites for a course are resolved, that course becomes available.

Why Use `head` Instead of `shift()`?

The queue is processed like this

for (let head = 0; head < queue.length; head++) {
  const course = queue[head]

Instead of repeatedly doing

queue.shift();

we keep an index pointing to the next item to process.

So the queue can grow while we iterate through it.

For example

queue = [0]

process 0
↓
queue = [0, 1]

process 1
↓
queue = [0, 1, 2]

head simply moves forward.

0 → 1 → 2
↑
head

Then

0 → 1 → 2
    ↑
   head

Then

0 → 1 → 2
        ↑
       head

Complexity

V = number of courses
E = number of prerequisite relationships

We build the graph once and process every course and edge.

Time: O(V + E)
Space: O(V + E)

👀 Let's View View It

This is probably the most interesting visualization of the three.

Because there are several things changing together.

graph
indegree
queue
head
completed

If I only read

indegree[next]--;
if (indegree[next] === 0) queue.push(next);

I understand the syntax.

But I may still ask:

Why did this course become available now?
Which prerequisite was removed?
Why is this course still not in the queue?
What does completed tell us?
Where exactly does the cycle get stuck?

https://dsa-view-view.vercel.app/#s=j.eyJlIjoiY291cnNlLXNjaGVkdWxlIiwibCI6InR5cGVzY3JpcHQiLCJtIjoidmVyaWZpY2F0aW9uIiwidiI6MX0

When we view the runtime, we can watch the dependencies disappear.

0 → 1 → 2

indegree = [0, 1, 1]
queue = [0]

       ↓ finish 0

indegree = [0, 0, 1]
queue = [0, 1]

       ↓ finish 1

indegree = [0, 0, 0]
queue = [0, 1, 2]

       ↓ finish 2

completed = 3

The code stops feeling like mysterious bookkeeping.

We're really doing one simple thing:

Keep taking courses that are ready, and make their dependent courses closer to being ready.

If eventually every course becomes ready

completed === numCourses

there is no blocking cycle.

If some courses never become ready

completed < numCourses

something is stuck in a cycle. 🎓😸

🧠 What Did We Actually Learn?

These three problems look very different.

But each one teaches a useful way of thinking.

Number of Islands

When you find one part of a connected group, explore the entire group before continuing.

What else is connected to this?

Invert Binary Tree

Let recursive calls solve the smaller subtrees first, then transform the current node using their results.

Can my children finish their work before I change this node?

Course Schedule

Process things that have no unresolved dependencies, then use them to unlock more work.

What can I safely process right now?

The implementations are not very long.

But each one introduces a different mental model.

DFS on a grid
Recursive tree transformation
Topological sorting

And once again, the syntax is not really the hardest part.

The difficult part is keeping track of the changing state.

Where are we?
What changed?
What is waiting?
What has already been visited?
Which recursive call are we inside?

Sometimes I can read every line and still lose the thread somewhere in the middle. 😿

That's exactly when I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Number of Islands with recursive grid traversal
Invert Binary Tree with recursion
Course Schedule with topological sorting

And more importantly, we followed what changed while each algorithm was running.

For Number of Islands, we watched connected land disappear as it became visited.

1 → 0

For Invert Binary Tree, we watched recursive calls go down and the tree change while they returned.

go down
↓
come back
↓
swap

For Course Schedule, we watched prerequisites disappear and new courses enter the queue.

indegree--
↓
0 prerequisites
↓
queue.push()

This is exactly the kind of thing I built DSA View View for.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

Especially when the implementation looks short, but your brain still says

Wait... what just changed? 😿

Seeing the runtime may make the idea much easier to follow.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

See you in the next article!

🛡️ Rate Limiting in Web Applications

Sun, 30 Aug 2026 06:19:02 +0000

In today’s API-driven world, applications face thousands—or even millions—of requests every day. While high traffic is great, it can also create challenges:

🔒 Security risks (brute force, DDoS attacks)
⚖️ Fair usage enforcement (avoid abuse of free tiers)
🚀 Performance stability (prevent one user from hogging resources)

This is where Rate Limiting comes in.

Rate limiting ensures a user, IP or client can only make a defined number of requests within a specific time window. It’s a cornerstone of modern, scalable APIs.

🧩 Why Do We Need Rate Limiting?

🔐 Security → Protect against brute force login attempts, API scraping, and DDoS attacks.
⚖️ Fair Usage → Prevent abuse of APIs, especially for freemium services.
🚀 Performance → Ensure backend resources are shared fairly among all users.
💰 Cost Control → Reduce infrastructure bills by blocking excessive or abusive requests.

⚙️ Common Rate Limiting Algorithms

1️⃣ Token Bucket

Requests are allowed if tokens are available.
Tokens refill at a fixed rate.
Commonly used (flexible + efficient).

🔧 Example: Allow 10 requests per second. If unused, tokens accumulate up to a max limit (burst handling).

2️⃣ Leaky Bucket

Works like water dripping from a bucket at a fixed rate.
Bursts are smoothed out.
Useful for evenly distributing traffic.

3️⃣ Fixed Window Counter

Count requests in a fixed time window (e.g., 100 requests per minute).
❌ Edge case: allows bursts at window boundaries.

4️⃣ Sliding Window Log

Keeps timestamps of requests.
Precise but memory-heavy for large scale.

5️⃣ Sliding Window Counter

Hybrid approach: averages counts across windows.
More accurate than fixed window, less heavy than logs.

🔧 Implementing Rate Limiting in Applications

Example in Go (Gin Framework)

package main

import (
"github.com/gin-gonic/gin"
"golang.org/x/time/rate"
"net/http"
"time"
)

func main() {
r := gin.Default()

// Create a limiter: 5 requests/sec, burst up to 10
limiter := rate.NewLimiter(5, 10)

r.GET("/api", func(c *gin.Context) {
if !limiter.Allow() {
c.JSON(http.StatusTooManyRequests, gin.H{"error": "Too many requests"})
return
}
c.JSON(http.StatusOK, gin.H{"message": "Request successful"})
})

r.Run(":8080")
}

✅ Each client is limited to 5 requests per second with a burst allowance of 10.

🚦 Rate Limiting with NGINX

NGINX can handle rate limiting at the web server or reverse proxy level, making it a powerful tool to protect your backend before requests hit your app.

⚙️ How It Works

NGINX uses two main directives:

limit_req_zone → Defines a shared memory zone to track requests (by IP or custom key).
limit_req → Applies the limit to endpoints.

🔧 Basic Example

http {
  # 1. Define rate limit zone (1 request/sec, burst 5)
  limit_req_zone $binary_remote_addr zone=api_limit:10m rate=1r/s;

  server {
    location /api/ {
      # 2. Apply rate limit
      limit_req zone=api_limit burst=5 nodelay;

      proxy_pass http://backend_service;
    }
  }
}

🔍 Explanation

Key: $binary_remote_addr → Track by client IP.
Rate: 1r/s → Allows 1 request per second per IP.
Burst: 5 → Short bursts up to 5 requests allowed.
nodelay: Burst requests are processed immediately.

✅ Advantages

Filters traffic before hitting your backend.
Can apply limits per endpoint (e.g., /login stricter than /products).
Lightweight & fast.

📊 Logs & Monitoring

Exceeded requests → logged as 503 (Service Unavailable).
Useful for tracking abuse & fine-tuning limits.

⚠️ Considerations

Avoid overly strict global limits (may block valid traffic).
Use $realip_remote_addr when behind a proxy/load balancer.
Always test before production rollout.

🔒 Best Practices for Rate Limiting

🎯 Apply stricter limits on sensitive endpoints (like /login).
🌍 Use different limits per client type (mobile app vs. server-to-server).
🧩 Combine server-level (NGINX/API Gateway) + app-level checks.
📊 Monitor logs & dashboards for blocked traffic trends.
🚀 Use distributed stores (Redis) for shared limits in multi-instance apps.

💡 Bonus Tips

✅ 429 Status Code: Always return HTTP 429 Too Many Requests with a helpful message.
✅ Retry-After Header: Tell clients when to retry. Example:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

✅ Graceful Degradation: Don’t just block—offer reduced functionality for non-critical requests.

🎯 Final Thoughts

Rate limiting is not just a performance tool—it’s a security guard, cost saver and reliability booster.

Whether you use algorithms in code, NGINX or API Gateways (Kong, Apigee, AWS API Gateway), implementing proper rate limiting ensures:

✔️ Fair usage
✔️ Secure endpoints
✔️ Scalable systems

🚀 The bottom line? Smart rate limiting makes APIs faster, safer, and fairer—for everyone.

💬 What approach do you use for rate limiting in your backend? Have you tried using Redis or NGINX rules? Let’s discuss in the comments!

Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in

Fri, 28 Aug 2026 14:46:28 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who struggles to make game sounds. 😿

Have you used DSA View View already? 👀👀

https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view--djo

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous article, we looked at:

Two Sum
Binary Search
Bubble Sort

https://dev.to/nyaomaru/is-learning-dsa-boring-lets-use-dsa-view-view-two-sum-binary-search-and-bubble-sort-374o

This time, let's try three more classic problems:

Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree

These problems introduce three very different ideas:

Stack
Pointer manipulation
Recursion

And all three can become confusing when we only stare at the final code.

So let's view what actually happens. 👀

I'm still learning DSA too, so let's learn together! 😸

🥞 Valid Parentheses

Let's start with Valid Parentheses.

Suppose we have this string:

()[]{}

Every opening bracket has a matching closing bracket.

So this is valid. ✅

But this

([)]

is not valid. ❌

Why?

Because the brackets close in the wrong order.

(
  [
)
  ]

The [ should be closed before the (.

So how can we keep track of that order?

Use a Stack

A stack follows a simple rule:

The last thing we put in is the first thing we take out.

This is called LIFO (Last In / First Out)

Imagine stacking plates.

    🍽️  ← remove first
    🍽️
    🍽️

The last plate we put on top is the first one we can take.

Parentheses work in the same way.

If we see:

(
[
{

then the brackets must close in reverse order

}
]
)

So a stack is a very natural fit.

Here is the implementation:

function isValid(s: string): boolean {
  const stack: string[] = [];

  const pairs: Record<string, string> = {
    ")": "(",
    "]": "[",
    "}": "{",
  };

  for (const char of s) {
    if (char === "(" || char === "[" || char === "{") {
      stack.push(char);
      continue;
    }

    if (stack.length === 0) return false;

    const target = stack.pop();
    if (target !== pairs[char]) {
      return false;
    }
  }

  return stack.length === 0;
}

The important part is what happens to stack.

Let's use

([])

At first

stack = []

We see

It's an opening bracket.

Push it.

stack = ["("]

Next,

Push again.

stack = ["(", "["]

Then,

This is a closing bracket.

What should it close?

And what is currently on top of the stack?

Perfect. ✅

So we remove it.

stack = ["("]

Finally,

It should close

The top of the stack is also

Pop!

stack = []

We reached the end with an empty stack.

Valid! 🎉

What About an Invalid Example?

Consider

([)]

We start the same way.

(
↓
stack = ["("]

[
↓
stack = ["(", "["]

Then we find

A ) needs

But the top of our stack is

They don't match.

expected: (
actual:   [

So we immediately know the string is invalid.

Complexity

We walk through the string once.

Time:  O(n)
Space: O(n)

In the worst case, the stack may contain all opening brackets.

👀 Let's View View It

This is where the stack becomes much easier to understand.

When we only read.

stack.push(char);

And

stack.pop();

It can be easy to lose track of what is actually inside the stack.

Especially with something like.

({[]})

What is on top right now?

Which opening bracket are we trying to close?

Instead of remembering everything in our head, we can follow the stack changing step by step.

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidmFsaWQtcGFyZW50aGVzZXMiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

Conceptually, we can see:

(
↓
[(]

{
↓
[(, {]

[
↓
[(, {, []

]
↓
[(, {]

}
↓
[(]

)
↓
[]

That's the whole idea.

Remember the opening brackets, and always match the most recent one first.

Stack suddenly feels much less mysterious. 🥞😸

🔗 Reverse Linked List

Next, let's reverse a linked list.

Suppose we have

1 → 2 → 3 → 4 → 5

We want

5 → 4 → 3 → 2 → 1

At first glance, this sounds simple.

Just reverse it!

But linked lists are a little different from arrays.

With an array, the values live in positions like

0  1  2  3  4
↓  ↓  ↓  ↓  ↓
1  2  3  4  5

A linked list instead consists of nodes pointing to the next node.

1 → 2 → 3 → 4 → 5 → null

Each arrow matters. To reverse the list, we need to reverse those arrows.

1 ← 2 ← 3 ← 4 ← 5

And this is where things can get confusing.

Because if we change an arrow too early...

we may lose the rest of the list. 😿

Three Important Variables

A common iterative solution uses three variables

prev
current
next

Here is the implementation:

function reverseList(head: ListNode | null): ListNode | null {
  let prev: ListNode | null = null;
  let current = head;

  while (current !== null) {
    const next = current.next;

    current.next = prev;

    prev = current;
    current = next;
  }

  return prev;
}

It's short.

But there is a lot happening inside these few lines.

Let's follow it carefully.

We start with

1 → 2 → 3 → null

And

prev = null
current = 1

Step 1: Save the Next Node

First

const next = current.next;

next = 2

Why do we need this?

Because we're about to change

1 → 2

If we change that arrow without remembering 2, we lose access to the rest of the list.

So first

Save where we need to go next.

Step 2: Reverse the Arrow

Now

current.next = prev;

Originally

1 → 2

But prev is

null

So now

1 → null

The first arrow has been reversed.

Step 3: Move `prev`

prev = current;

prev = 1

Step 4: Move `current`

Finally

current = next;

We saved 2 earlier.

So now

current = 2

Our state looks like this

null ← 1    2 → 3 → null
       ↑    ↑
      prev current

Then we do exactly the same thing again.

Save:

next = 3

Reverse

2 → 1

Move

prev = 2
current = 3

Now

null ← 1 ← 2    3 → null
           ↑    ↑
          prev  current

One more time

next = null

Reverse

3 → 2

Move

prev = 3
current = null

And now

null ← 1 ← 2 ← 3
               ↑
              prev

The loop stops because

current === null

And prev is the new head.

return prev;

Done! 🎉

Complexity

We visit each node once.

Time:  O(n)
Space: O(1)

We don't create another linked list.

We only move a few pointers.

👀 Let's View View It

This is exactly the kind of code that I find difficult to understand by reading alone.

These four lines:

const next = current.next;
current.next = prev;
prev = current;
current = next;

look simple.

But when I first see code like this, my brain starts asking.

Wait.

- Where is current now?
- Did we lose next?
- Which arrow changed?
- What exactly does prev point to?

😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoicmV2ZXJzZS1saXN0IiwibCI6InR5cGVzY3JpcHQiLCJtIjoidmVyaWZpY2F0aW9uIiwidiI6MX0

When we visualize each step, we can actually follow the pointers moving.

prev      current
 ↓           ↓
null         1 → 2 → 3

      ↓↓↓

null ← 1     2 → 3
       ↑     ↑
      prev current

      ↓↓↓

null ← 1 ← 2     3
           ↑     ↑
          prev current

      ↓↓↓

null ← 1 ← 2 ← 3
               ↑
              prev

The algorithm becomes much simpler when we stop thinking of it as four mysterious assignments.

It's really just

Save next
  ↓
Reverse arrow
  ↓
Move prev
  ↓
Move current
  ↓
Repeat

Nice! 🔗😸

🌳 Maximum Depth of Binary Tree

Finally, let's look at a tree.

Consider this binary tree.

What is its maximum depth?

The longest path from the root to a leaf contains three nodes:

So the answer is.

How can we calculate that?

Think About a Smaller Tree

Suppose we are standing at one node.

We don't really need to understand the entire tree at once.

We only need to ask.

How deep is the left subtree?

How deep is the right subtree?

Then choose the larger one.

And add 1 for the current node.

That's exactly what this implementation does.

function maxDepth(root: TreeNode | null): number {
  if (root === null) {
    return 0;
  }

  const leftDepth = maxDepth(root.left);
  const rightDepth = maxDepth(root.right);

  return Math.max(leftDepth, rightDepth) + 1;
}

The important idea is

Math.max(leftDepth, rightDepth) + 1;

But recursion can feel strange.

When we call

maxDepth(root.left);

where does the current function go?

And how do all those calls eventually become one number?

Let's follow a small example.

We start at

But before 1 can know its depth, it asks its left child

maxDepth(2)

Node 2 asks

maxDepth(4)

Node 4 has no children.

So both sides eventually reach

null

And

maxDepth(null);

returns

Therefore node 4 can calculate

max(0, 0) + 1
= 1

Now we return to node 2.

Its left side has depth

Its right side is null

max(1, 0) + 1
= 2

Now return to node 1.

Eventually its right subtree also returns

So node 1 gets

leftDepth = 2
rightDepth = 1

And calculates

max(2, 1) + 1
= 3

Answer

🎉

The Interesting Part: Going Down and Coming Back Up

This is what makes recursion interesting.

First, the function calls go down the tree.

1
↓
2
↓
4
↓
null

But the answers are built while returning back up.

null → 0
4    → 1
2    → 2
1    → 3

So recursion isn't only

Keep calling the same function.

There are really two directions.

Go down
  ↓
Reach the base case
  ↓
Return values back up

The base case here is

if (root === null) {
  return 0;
}

Without it, the recursion would have no place to stop.

Complexity

Every node is visited once.

Time: O(n)

The recursive call stack depends on the height of the tree.

Space: O(h)

where h is the height of the tree.

For a balanced tree, that is roughly

O(log n)

In the worst case, if the tree looks like a linked list

the depth can become

O(n)

👀 Let's View View It

Recursion is probably my favorite example for visualization.

Because the final implementation is tiny

const leftDepth = maxDepth(root.left);
const rightDepth = maxDepth(root.right);

return Math.max(leftDepth, rightDepth) + 1;

But a lot is hidden inside those function calls.

When reading the code, it can feel like

maxDepth()
inside maxDepth()
inside maxDepth()
inside maxDepth()
...

Where are we now? 😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidHJlZS1kZXB0aCIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9

When we step through the execution, we can follow both parts

Going down

1
↓
2
↓
4
↓
null

and then

Coming back

null → 0
↓
4 → 1
↓
2 → 2
↓
1 → 3

That makes the recursive idea much easier to see.

Ask the smaller subproblems for their answers, then use those answers to build the current answer.

🌳😸

🧠 What Did We Actually Learn?

These three problems look completely different.

But each one introduces a very useful way of thinking.

Valid Parentheses

Use a stack when the most recent item needs to be handled first.

What was the last thing I opened?

Reverse Linked List

When changing references, save what you still need before breaking the old connection.

Where do I need to go next before I change this pointer?

Maximum Depth of Binary Tree

Break a problem into smaller versions of the same problem.

Can I get the answers from my children and build my answer from them?

This is one reason I like learning these problems together.

The implementations are not very large.

But each one introduces a completely different mental model

Stack
Pointer
Recursion

And those mental models are much harder to learn than the syntax itself.

Sometimes the code tells us what happens.

But I also want to see how it happens.

I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Valid Parentheses with a stack
Reverse Linked List with pointer manipulation
Maximum Depth of Binary Tree with recursion

And more importantly, we followed the state while each algorithm was running.

We watched change the stack.

stack.push() / stack.pop()

We watched move through a linked list.

prev
current
next

And we watched recursive calls travel down a tree and return their answers back up.

This is exactly the kind of thing I built DSA View View for.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

Especially if a solution feels like

I understand every line individually... but somehow I still don't understand the whole thing. 😿

Seeing the runtime may connect those pieces together.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

See you in the next article!

Learning To Code Is A Memory Problem, Not A Video Problem

Fri, 28 Aug 2026 06:01:50 +0000

Most of us learned to code by watching somebody else do it, and then discovered that watching and doing are two different skills. The tools that moved the needle were never the ones that explained better, they were the ones that made me produce the answer from memory before showing it to me.

The Tutorial Trap

You follow a tutorial, everything works, and you feel like you understand it. A week later you open a blank file and cannot remember the shape of the thing you just built. That gap has a name in learning research: recognition is not recall. Reading code you have already seen feels fluent, and fluency is a terrible predictor of whether you can write it again.

The uncomfortable version works better. Close the tab, write the thing from memory, get it wrong, then check. It feels worse and it is measurably more effective, which is exactly why almost nobody does it voluntarily.

Turn The Docs Into Questions

This is where the current crop of AI study tools is genuinely useful, and it has nothing to do with them writing code for you. Feed a spec, an RFC, or a page of docs into a quiz generator and you get questions about the material back instead of a summary of it. You then have to answer them, which is the whole point.

The same idea covers everything that is pure memorization with no logic to reason from: shell flags, SQL window function syntax, the git subcommands you touch twice a year, HTTP status codes past the obvious ones. A flashcard generator built from your own notes beats a public deck, because it uses your wording and it targets your gaps rather than somebody else's.

Solvers That Show Their Work

There is a real difference between a tool that returns an answer and a tool that returns the steps. For anything with math underneath it, and that now includes complexity analysis, query planning, and most of the graphics and ML work people are moving into, the steps are the entire lesson. The answer is worth nothing to you a week later.

The practical test when picking one: can you cover the last line and predict it? If yes, the tool is teaching. If the output is a black box with a number at the bottom, you have outsourced the exact part you were trying to learn.

Where Summarizers Help And Where They Hurt

Summarizers are triage. They are very good at telling you whether a forty page paper is worth your afternoon, and very bad at putting that paper in your head. Use one to decide what to read, never as a substitute for reading the thing you decided mattered.

The Takeaway

Every one of these tools shares a failure mode. If it removes the effort, it removed the learning along with it. Pick the ones that hand the work back to you.

I keep a running comparison of the current crop, quiz generators, flashcard makers, math solvers and the rest, in this guide to AI study tools.

Quantum Mechanics For Developers: The Physics Under The Hardware You Ship

Wed, 26 Aug 2026 22:45:18 +0000

Most of us here write code that runs on transistors, and almost none of us ever had a reason to ask why a transistor works at all. This is a short tour of the physics that answers that question, written for developers rather than for physicists.

Quantum mechanics has a reputation problem among people who write software. It arrives as cats in boxes and particles in two places at once, which makes it sound like philosophy rather than engineering. It is neither. It is the most experimentally verified theory in physics, its predictions have never once failed, and it is the reason semiconductors, lasers and MRI machines exist at all.

The Principles That Do The Work

Five ideas carry almost all of the weight.

Quantization. Energy comes in discrete packets. An electron in an atom is restricted to specific energy levels, like a staircase with no ramp between the steps. Planck found this in 1900 while working out why hot objects glow the colors they do.

Wave-particle duality. Send electrons through a crystal and they produce an interference pattern like water waves through two openings. Detect those same electrons on a screen and each one arrives as a single point. Neither description is complete on its own.

Superposition. A system can sit in a combination of states until a measurement forces one outcome. This is not a statement about our ignorance of some hidden value. No theory that assigns pre-existing definite values to every property can reproduce all the quantum predictions.

Entanglement. Two particles become correlated such that neither has a state you can describe independently, at any separation. Einstein called it spooky action at a distance and believed it showed the theory was incomplete.

Tunneling. A particle crosses an energy barrier it classically cannot cross, because the wave function decays through the barrier rather than stopping at it, and still has a nonzero value on the far side.

The Experiments That Forced It

The double-slit experiment is the center of all of it. Particles sent one at a time build an interference pattern, which is wave behavior. Add a detector that records which slit each particle went through and the pattern disappears. Feynman said this single experiment contains the only mystery in quantum mechanics, because everything else is a variation of the same puzzle.

The photoelectric effect settled the question of whether light is quantized. Shine light on a metal and electrons are ejected, but only above a threshold frequency, no matter how intense the light is. Einstein explained it in 1905 with photons carrying energy proportional to frequency, and it earned him the Nobel Prize in 1921.

Stern-Gerlach in 1922 sent silver atoms through a non-uniform magnetic field and got two distinct beams instead of a continuous spread, which is the first direct evidence of quantum spin.

Bell test experiments, from Alain Aspect in 1982 through the loophole-free versions in 2015, ruled out local hidden variable explanations for entanglement. That is about as close as physics gets to closing an argument.

Where It Shows Up In Your Stack

Semiconductors are quantum band structure applied at industrial scale, which means every transistor you have ever run code on is a quantum device. Flash memory writes and erases by tunneling electrons through an oxide layer. Lasers depend on quantized energy levels and stimulated emission. Scanning tunneling microscopes image individual atoms using tunneling current as the signal.

And quantum computing treats superposition and entanglement as a computational resource rather than a curiosity, which is why the field cares so much about coherence times. If you want the computing angle specifically, the quantum computing guide covers qubits, gates and error correction without the marketing.

The Takeaway

You do not need the mathematics to get value out of the intuition. Knowing that energy is quantized, that measurement is not passive, and that tunneling is a real transport mechanism changes how you read hardware documentation and how much sense device physics makes. The full walkthrough of the principles, the experiments and the applications is in the quantum mechanics guide, and it is written for people coming in without a physics background.

C++ unique_ptr: reset() vs release() vs std::move

Sat, 22 Aug 2026 15:48:55 +0000

When you first learn std::unique_ptr, three things confuse almost everyone: release(), reset(), and std::move. They all look like they "give something up", but they do very different things. This post explains what each one really does, with short examples.

1. The key to understanding `release()`

release() means: "I don't want to manage this object anymore."

It does not delete the object. It just gives up ownership and hands the raw pointer back to you. After the call, the smart pointer is empty (get() returns nullptr), and you are now responsible for deleting the object.

Parameters
(None)

Return value
The raw pointer to the managed object, or nullptr if there was no managed object.

Example

#include <memory>
#include <iostream>

int main(){
std::unique_ptr<int> ptr = std::make_unique<int>(100);
int* raw = ptr.release(); // ptr gives up ownership, ptr is empty now
if(!ptr)
std::cout<< *raw << std::endl;
delete raw; // we must delete raw manually
}

Warning: release() is rarely what you want:

If you forget to capture the returned raw pointer, the object leaks immediately.
After taking the raw pointer, you must remember to delete it yourself — you are back to manual raw-pointer management.
The one legitimate use: handing the object to a legacy C API that requires a raw pointer and promises to take ownership.

2. The right way to use `reset()`

reset() replaces the managed object.

Called with no argument, ptr.reset() deletes the object it owns and becomes empty. If you pass in a new pointer, the old object is destroyed first, and the smart pointer then takes ownership of the new one.

Parameters
ptr - (optional) pointer to a new object to manage

Example

#include <memory>
#include <iostream>

int main(){
std::unique_ptr<int> ptr = std::make_unique<int>(100);

ptr.reset();  // delete the original object, ptr is empty.

ptr.reset(new int(10)); // delete the old object, manage the new pointer.
}

3. Comparing `release()` and `reset()`

release(): does not delete the old object — it hands the raw pointer back to you
reset(): deletes the old object (if any), then manages the new pointer you pass in
Both make the smart pointer lose control of the old resource; the difference is who deletes the object and when

	release()	reset()
Old object destroyed?	No — you must delete it yourself	Yes, immediately
Smart pointer after call	empty	manages the new pointer (or nothing)
Returns	the raw pointer	nothing

4. How `std::move` fits in

std::move does not move anything by itself. It only marks an object as "moved-from" — a permission slip saying "you may take this object's resources instead of copying them".

Parameters
ob - the object to be moved

Example

class MyClass{
std::string data;
public:
MyClass(std::string&& str) : data(std::move(str)) {}
};

std::vector<std::string> v;
std::string temp = "example";
v.push_back(std::move(temp));

#include <memory>
#include <iostream>

int main(){
std::unique_ptr<int> ptr1(new int(10));
std::unique_ptr<int> ptr2 = std::move(ptr1);
if(!ptr1)
std::cout<< "ptr1 is empty" << std::endl;
if(ptr2)
std::cout<< "ptr2 owns the resource and value is: "<<*ptr2 << std::endl;
}

Why is std::move so common with smart pointers?
std::unique_ptr has exclusive ownership: it cannot be copied, because two owners would delete the same object twice. So the only way to transfer ownership between unique_ptrs is std::move.

References

AI makes learning faster. But is faster always better ?

Thu, 20 Aug 2026 20:19:05 +0000

AI is an incredible learning tool. I said it in my previous article, and I still believe it.

But after spending months learning new web frameworks and technologies with AI as my main companion, I noticed something uncomfortable.

I was moving fast. But was I really understanding?

The old way was painful and powerful

Before AI, learning a new technology meant suffering.

You'd hit a bug. You'd search for hours. Read Stack Overflow threads, YouTube videos. Try things that didn't work. Get frustrated. Sleep on it. Come back the next day and finally click. It works.

That process was slow. Sometimes humiliating. Often exhausting.

But here's what I didn't realize at the time: that struggle was doing something to my brain.

Every hour spent searching, failing, and retrying was building a deep, almost physical understanding of the concept. When I finally found the solution, I owned it. I knew not just the answer, but every wrong path around it.

Now I just ask. And get an answer. Instantly.

With AI, that whole painful loop collapses into a single message.

Bug? Ask AI. Confusing concept? Ask AI. Don't know the right syntax? Ask AI.

The answer comes in seconds. Clean. Well-explained. Usually correct.

And I move on.

The problem is: moving on is not the same as understanding.

What I actually noticed

Learning Vue, Nuxt, and other web technologies with AI, I realized something: I needed to build far more projects than before to reach the same depth of understanding.

Without AI, one difficult project could teach me something deeply because I had wrestled with every problem alone.

With AI, I could finish that same project twice as fast, but the understanding was shallower. I had to build three or four more projects to reach the same level of genuine comprehension.

The friction wasn't just wasted time. The friction was the learning.

This doesn't mean AI is bad for learning

I'm not saying we should go back to suffering alone for hours.

What I'm saying is: we need to be intentional.

A few things that help me:

Try first, ask second. Before asking AI, I give myself at least 15-20 minutes to struggle alone. The struggle primes my brain to actually absorb the answer.
Ask AI to explain, not just fix. Instead of "fix this bug", I ask "why is this happening and what does it teach me about how this framework works?"
Build more, copy less. More small projects from scratch. Less copy-pasting AI-generated code without understanding it.

The bottom line

AI accelerates learning. But depth still comes from doing really doing and from the discomfort of not knowing yet.

The goal isn't to avoid AI. It's to use it without losing the struggle that makes knowledge stick.

Have you felt this too? Are you learning faster but sometimes feeling like things don't fully sink in? Let's talk in the comments.

Follow my journey on Facebook I share thoughts on tech, learning, and building in the open.

Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort)

Wed, 19 Aug 2026 15:14:55 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who dislikes crowded places, so I'm planning to take a quiet vacation in September. 🏝️

Have you used DSA View View already? 👀👀

https://coderlegion.com/22758/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

But just introducing the tool is not enough.

Can it actually help us understand DSA?

In this article, we'll walk through three classic problems:

Two Sum
Binary Search
Bubble Sort

We'll first understand the algorithm, and then see what is actually happening with DSA View View.

Let's learn together! 😸

🗺️ Two Sum

Let's start with a very famous problem.

Given an array of numbers and a target value, find the indices of two numbers whose sum equals the target.

For example,

nums = [2, 7, 11, 15];
target = 9;

The answer is

[0, 1];

Because

2 + 7 = 9

Simple!

So, how should we find them? 🤔

Brute Force

The easiest approach is probably checking every possible pair.

function twoSum(nums: number[], target: number): number[] {
  for (let i = 0; i < nums.length; i++) {
    for (let j = i + 1; j < nums.length; j++) {
      if (nums[i] + nums[j] === target) {
        return [i, j];
      }
    }
  }

  return [];
}

This works.

But if the array becomes large, we may need to compare a lot of pairs, right?

The time complexity is O(n²)

Can we avoid checking the same values again and again?

Yes.

Let's use a Map.

function twoSum(nums: number[], target: number): number[] {
  const seen = new Map<number, number>();

  for (let i = 0; i < nums.length; i++) {
    const current = nums[i];
    const need = target - current;

    if (seen.has(need)) {
      return [seen.get(need)!, i];
    }

    seen.set(current, i);
  }

  return [];
}

The important part is this 👇

const need = target - current;

Instead of asking

Which two numbers should I combine?

we ask

What number do I need to complete the target?

Let's follow the example.

At first

current = 2
target = 9

need = 9 - 2
     = 7

Have we already seen 7?

No.

So we remember 2.

seen = {
  2 → 0
}

current = 7
target = 9

need = 9 - 7
     = 2

Have we already seen 2?

Yes! 👀👀

seen = {
  2 → 0
}

return [0, 1];

Done!

Because we only need to walk through the array once, the time complexity becomes.

Time:  O(n)
Space: O(n)

👀 Let's View View It

The implementation is quite small.

But when I was first learning this pattern, this part still felt a little magical.

if (seen.has(need))

Where did need come from?
What is inside seen at this moment?
Why does checking the previous values solve the problem?

This is exactly where visualization helps.

{% embed https://dsa-view-view.vercel.app/#s=j.eyJlIjoidHdvLXN1bSIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9 %}

With DSA View View, we can move through the runtime one step at a time and inspect how the values change.

2
↓
Need 7
↓
Remember 2
↓
7
↓
Need 2
↓
Found 2!
🎉

Now the Map is not just some mysterious trick.

We can actually follow the idea.

Remember what we have already seen, and check whether the value we need is there.

Nice! 😸

🔍 Binary Search

Next is Binary Search.

Suppose we have this sorted array

[1, 3, 5, 7, 9, 11, 13]

And we want to find

Of course, we could start from 1 and check every number.

1 → 3 → 5 → 7 → 9 → 11

That works.

But Binary Search does something smarter.

Instead of checking from the beginning, it checks the middle.

[1, 3, 5, 7, 9, 11, 13]
          ↑
         mid

Our middle value is 7.

We are looking for 11.

11 > 7

Because the array is sorted, we already know something very useful.

Everything on the left side of 7 is also smaller than 11.

So, we don't need that half anymore. 👋

[1, 3, 5, 7, 9, 11, 13]
             └───────┘
               search

Now we check the middle of the remaining range.

[9, 11, 13]
     ↑
    mid

And

11 === 11

Found it! 🎉

Here is the implementation.

function binarySearch(nums: number[], target: number): number {
  let left = 0;
  let right = nums.length - 1;

  while (left <= right) {
    const mid = Math.floor((left + right) / 2);

    if (nums[mid] === target) {
      return mid;
    }

    if (nums[mid] < target) {
      left = mid + 1;
    } else {
      right = mid - 1;
    }
  }

  return -1;
}

There are three important variables.

left
right
mid

They represent the current search range.

For our example, they start like this

left = 0
right = 6
mid = 3

[1, 3, 5, 7, 9, 11, 13]
 ↑        ↑          ↑
left     mid       right

Because

nums[mid] < target;

we move left.

left = mid + 1;

Now

[1, 3, 5, 7, 9, 11, 13]
             ↑   ↑   ↑
           left mid right

And 11 is found.

Why Is Binary Search Fast?

This is the interesting part.

Each step removes about half of the remaining candidates.

If there are 1,000 values, we don't necessarily need 1,000 checks.

It becomes roughly

1000
↓
500
↓
250
↓
125
↓
...

That's why Binary Search has

Time:  O(log n)
Space: O(1)

But there is one very important condition.

The data must be sorted.

Without sorted data, we cannot safely throw away half of the search range.

👀 Let's View View It

Binary Search is one of the algorithms that made me want a visualization tool in the first place.

The code itself is short

left = mid + 1;

right = mid - 1;

Easy.

But when learning it, I sometimes found myself thinking:

Wait... which part are we searching now? 😿

{% embed https://dsa-view-view.vercel.app/#s=j.eyJlIjoiYmluYXJ5LXNlYXJjaCIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9 %}

When we visualize left, mid, and right, the idea becomes much easier to follow.

We are not randomly changing three numbers.

We are continuously shrinking the search area.

███████████████

       ↓

        ███████

       ↓

          ███

       ↓

           █

That's Binary Search!

Cut the unnecessary half.

Then cut it again. And again. And again.

Until we find the answer. ✂️😸

Bubble Sort

Finally, let's sort something!

Consider this array.

[5, 1, 4, 2, 8];

We want.

[1, 2, 4, 5, 8];

Bubble Sort repeatedly compares two neighboring values.

If they are in the wrong order, it swaps them.

Let's look at the beginning.

[5, 1, 4, 2, 8]
 ↑  ↑

Compare

5 > 1

So swap them.

[1, 5, 4, 2, 8]

[1, 5, 4, 2, 8]
    ↑  ↑

Again

5 > 4

Swap!

[1, 4, 5, 2, 8]

And continue.

[1, 4, 5, 2, 8]
       ↑  ↑

5 > 2

Swap!

[1, 4, 2, 5, 8]

Eventually, larger values move toward the end of the array.

They kind of...

bubble up.

That's why it is called Bubble Sort.

Here is a simple implementation:

function bubbleSort(nums: number[]): number[] {
  for (let i = 0; i < nums.length - 1; i++) {
    for (let j = 0; j < nums.length - i - 1; j++) {
      if (nums[j] > nums[j + 1]) {
        [nums[j], nums[j + 1]] = [nums[j + 1], nums[j]];
      }
    }
  }

  return nums;
}

We repeatedly compare

nums[j];

And

nums[j + 1];

and swap them when necessary.

After one full pass, the largest remaining value reaches its correct position near the end.

So on the next pass, we don't need to check that position again.

That's why the inner loop contains.

nums.length - i - 1;

Complexity

Bubble Sort isn't very fast for large arrays.

Its time complexity is

Time:  O(n²)
Space: O(1)

So I probably won't suddenly replace production sorting with Bubble Sort tomorrow. 😸

But as a learning example, I really like it.

Why?

Because you can see the algorithm working.

👀 Let's View View It

This is probably the most visually satisfying one of the three.

{% embed https://dsa-view-view.vercel.app/#s=j.eyJlIjoiYnViYmxlLXNvcnQiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ %}

Instead of only reading

[nums[j], nums[j + 1]] = [nums[j + 1], nums[j]];

we can follow the values moving through the array.

[5, 1, 4, 2, 8]

 ↓ swap

[1, 5, 4, 2, 8]

    ↓ swap

[1, 4, 5, 2, 8]

       ↓ swap

[1, 4, 2, 5, 8]

Then another pass begins.

The code contains nested loops, indexes, comparisons, and swaps.

But visually, the basic rule is extremely simple:

Compare neighbors. If the left one is bigger, swap them.

Repeat. Repeat. Repeat.

Sorted! 🎉

🧠 What Did We Actually Learn?

These three problems look quite different.

But each one introduces a useful way of thinking.

Two Sum

Remember information from previous steps.

Have I already seen what I need?

Binary Search

Use what we already know to remove impossible candidates.

Can I safely discard half of the search space?

Bubble Sort

Break a larger problem into many small comparisons.

Are these two values in the correct order?

This is one of the things I find interesting about learning DSA.

At first, the implementation can look like a collection of indexes, loops, conditions, and mysterious variables.

But behind the code, there is usually a much simpler idea.

And sometimes I don't fully understand that idea just by staring at the code.

I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at three classic algorithms:

Two Sum with a Map
Binary Search
Bubble Sort

And more importantly, we looked at how the data changes while they run.

I think this is where visualization can be especially useful.

Reading the final implementation tells us what the code is.
Stepping through it helps us understand why it works.

That's exactly why I built DSA View View.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try taking a problem you already solved and viewing it step by step.

You may notice something you didn't notice when only reading the code. 👀

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

And my DSA View View has launched at TinyLaunch! 🚀 Please take a loot 👇

https://www.tinylaunch.com/launch/17804-dsa-view-view

See you in the next article!

Premature Optimization of Your Brain: Why Your Learning Roadmap Is Bad Architecture

Sun, 09 Aug 2026 10:17:36 +0000

Picture the classic beginner. Fifty tabs open. One says "Python Basics." Another says "How to Set Up a Kubernetes Cluster on a Raspberry Pi With No SIM Card," which, sure, bud, that's definitely the blocker between you and your first job.

This is the guy architecting a system for 100 million users before he's shipped a single line of working code. Before he has one client. Before he has anything except vibes and a folder called "learning-roadmap-final-v3." He thinks preparation is the path. It isn't. It's just a really elaborate way of not starting. Every senior dev alive will tell you premature optimization is the root of all evil, nod sagely over their coffee, and then go home and do the exact same thing to their own brain — pre-allocating memory for variables that are never, ever going to be declared. Your skull is not a Kubernetes cluster. You don't need seventeen microservices of knowledge before you've written a monolith that actually runs.

And the panic isn't coming from nowhere. Some YouTuber told you that if you don't know Docker, Next.js, and whatever's trending this week, you're basically unemployable, doomed, going to die alone eating instant noodles over a laptop that still has training wheels on. So instead of building the boring contact form you actually need — the one that would take you an afternoon — you go memorize a whole stack you have nowhere to put yet. I've watched a guy spend three weeks on Kubernetes YAML for a side project that gets, on a good day, forty visitors. Forty. It's still running on python manage.py runserver energy underneath, he just wrapped it in enough infrastructure to survive a Black Friday it will never see. That's cargo cult programming, textbook definition. You're out there building an airplane out of straw and praying it takes off, because somewhere a guy in a suit told you the real planes have straw too. Learning tech "just in case" isn't ambition, it's anxiety wearing a hoodie, and the resource it burns fastest isn't time. It's focus — the one thing you actually needed for that contact form. Your learning stack currently looks like a government transit project — way over-budget and still doesn't work. What you needed was a bicycle. You built a jet you don't know how to fly and can't afford fuel for.

So let's fix the actual root cause: you've been treating laziness like the villain of this story when it's actually the hero nobody thanked. Laziness isn't your enemy. It's your firewall — the thing blocking a DDoS attack of information you didn't ask for and don't need. A genuinely good engineer is a lazy one, and I mean that as the highest compliment I own. A good engineer can't be bothered learning something they won't use this afternoon. Healthy laziness says: "I don't need Kubernetes until my monolith on one server actually starts falling over." Trying to learn it before that is like shoveling your driveway in the middle of a January blizzard, eh? Just pointless and cold, because five minutes later it's buried under a fresh layer of stuff you still don't need. You're allowed to look a shiny new technology dead in the eye and say "I'm not learning you until you become my actual problem." That's not a character flaw. That's discipline with better PR. Think JIT compilation for your brain — compile the knowledge exactly when it's about to execute, don't sit there caching the entire internet in RAM on the off chance you'll need it in 2031.

Once you've given yourself permission to be lazy about the right things, the next move is obvious, even if it feels wrong at first: just make it compile. YAGNI, applied to your actual life. Your only job while learning is to shrink the gap between "I know nothing" and "it runs," as fast as humanly possible. Ugly is fine. Duct tape and hardcoded values are fine. Security holes the size of Jupiter — also, temporarily, fine. Ship the MVP. Get it running. Security, optimization, containers, clean architecture, all of that gets bolted on later, once you actually have context and a real need instead of a hypothetical one you invented to feel productive. You learn ten times faster from a live, bleeding error in production than from a book chapter preemptively warning you it might happen someday. That contact form from three paragraphs ago? Hardcode the email address. Skip the queue. Skip the retry logic. Ship it this afternoon, watch it break exactly once in some boring, specific way, and fix that one real problem instead of the fifty imaginary ones you were prepping for. Agile exists for a reason, and it's not just to give product managers something to say in standup. Write it working. Then make it pretty. Then, only then, make it fast.

And once you're actually building things instead of pre-optimizing a brain that hasn't shipped anything yet, you hit the last real obstacle. It isn't technical at all. It's letting go of FOMO. The tech industry manufactures garbage faster than you can Google it. Trying to fully keep up is about as realistic as affording a detached house in Toronto on a junior dev salary — technically a number exists where it's possible, practically nobody you know has actually done it. You will never keep up, full stop, and the sooner you accept that, the sooner you stop feeling like a failure for it. Your real skill was never storage capacity. It's retrieval speed, and knowing what to throw out. Turn on your internal garbage collector. Start ruthlessly deallocating anything sitting in your head that isn't providing value right now. If you don't sweep unused objects out of memory, the whole system hangs — and your brain, despite what your CS degree might've implied, is not exempt from the laws of computer science it teaches.

So, what do you think, eh? Or are you too busy writing YAML files for your zero-user startup to reply? Let me know which topics we should crack open next.

The Missing Semester of Your Tech Education: How to Stop Being a High-Level Puppet

Fri, 07 Aug 2026 11:15:42 +0000

Hey everyone. Been a minute, eh? Real talk — I went through a rough patch in my dev life the last while, the kind that makes you question whether you actually like this industry or just got really good at pretending. I'm back now, and I didn't want to show up empty-handed after ghosting you all like that, so here's a proper one. Grab your double-double, maybe a Timbit or six, this is a long-ish ride, but I promise it's a friendly one.

And listen — before we get into the roasting, because there will be some roasting, I want to say this part sincerely: if you're reading this and you're early in your career, or mid-career and feeling behind, none of what follows is meant to make you feel small. It's meant the way a buddy tells you there's spinach in your teeth before the big meeting. Annoying for a second, genuinely useful after. We're all just figuring this out together, one Segfault at a time.

Episode 1: The High-Level Illusion

Here's an uncomfortable little exercise. Ask a working web developer what an L1 cache line is. Ask them why a context switch costs anything at all. Ask them what a branch predictor actually predicts. Watch the face. That face is the whole problem.

Modern languages didn't just make us productive, they made us spoiled. The garbage collector taught an entire generation to stop thinking about object lifetimes at all — memory just, sort of, handles itself, so why worry? You write obj = JSON.parse(data) or slap an ORM on your queries and your brain files it under "one line, basically free." Underneath that one line is a small riot of allocations, string parsing, and serialization overhead you never agreed to pay for, you just didn't get the bill yet.

The processor became a black box on purpose. Nobody's malicious about it, that's just what abstraction is for. But you can't actually reason about why your "high-performance" microservice chokes under load if the hardware it runs on is a total mystery to you. You're debugging a car you've never opened the hood of, and somehow surprised when "just add more RAM" stops working.

Episode 2: The Bare Metal Baptism

There's exactly one cure for high-level brain rot, and it's unpleasant on purpose: go write something in C. No libraries holding your hand. No pre-built hash map, no pre-built linked list. Build your own, badly, then build it again less badly.

You will hit Segfault #1. Then #2. Then somewhere around #50 you'll start actually understanding what memory looks like instead of just trusting that it works. Valgrind will roast you for leaks you didn't know you were capable of creating. That pain is doing something — it's wiring an actual, physical map of memory into your brain, the kind no tutorial video gives you secondhand.

Once you've fought with raw pointers and manual malloc/free for a while, you start understanding things you couldn't have been talked into believing otherwise: why copying big structs in a hot loop is a crime, why the stack is faster than the heap and why that actually matters, why "it's fine, the language handles it" was never really true, just deferred. This knowledge doesn't stay in C. It follows you into Python, into Java, into whatever you write for the rest of your career, and it makes you dangerous in the good way.

And hey — if you're mid-Segfault-thirty right now, cursing my name, that's normal. Everyone who's good at this went through the exact same ugly stretch. Nobody was born understanding pointers, we all just eventually got tired of being confused and pushed through it, eh.

Episode 3: Literacy of the Masters

Writing your own janky code in total isolation is a dead end, and I say that with love. At some point you have to go read the people who actually built this industry, or you'll spend your whole career reinventing worse versions of things that already exist.

Juniors write endless little wheels off dumb tutorials because they've genuinely never seen what beautiful, battle-tested code looks like. So go look. Crack open Redis — genuinely gorgeous, minimal C. Read SQLite. Read nginx if you're feeling brave. These aren't textbooks written by theorists trying to teach you a concept. This is code holding up terabytes of real traffic, written by people who had to get it right.

Don't try to swallow the whole thing at once, that's a losing game. Find the entry point — main, usually — and figure out the one core data structure the whole thing revolves around, like Redis's sds string implementation. Watch how the authors handle errors. Watch how they manage memory without losing their minds. That's the actual architecture school nobody enrolled you in.

Episode 4: The Cloud Scam and Bare Metal Reality

Somewhere along the way, the industry forgot how to optimize software and started just throwing investor money at problems instead. That's the honest version of the story nobody puts in the pitch deck.

You get told you need Kubernetes, Lambda, full serverless, and twenty VMs to scale a site pulling ten thousand visitors. For most of you reading this, that's not engineering, that's a scam wearing a hoodie. A properly written, async, actually-optimized service on a single fifty-dollar bare metal box can push tens of thousands of requests per second at single-digit-millisecond latency. No cluster required. No YAML novel required.

Before you touch Kubernetes, you should be able to SSH into a server, configure iptables/ufw without googling every flag, understand what systemd is actually doing when it starts your service, and hand-edit an nginx config without breaking production. If you can't administer one server calmly, adding nine more of them isn't going to fix that, it's just going to multiply the panic.

Episode 5: The AI Autocomplete Trap

Okay, this one's the elephant in the room, and I'd be a phony writing a whole post about high-level illusions in 2026 and not mentioning the biggest one currently happening live, in real time, to basically all of us.

AI coding tools are genuinely great, I'm not here to be the grumpy guy yelling at the cloud, no shade to actual clouds either after Episode 4. Copilot, Cursor, whatever you're using — they're a real productivity boost, and pretending otherwise is just cope. But here's the quiet, uncomfortable thing happening underneath the convenience: we just added a whole new abstraction layer on top of all the other abstraction layers, and this one doesn't even ask you to understand the code it hands you. It just hands it to you, confident, formatted nicely, and you tab-complete your way past actually reading it.

That's the new version of the same old sin from Episode 1, just wearing a nicer jacket. Before, you didn't understand what the garbage collector was doing. Now you might not even understand what the function you just accepted does, because you never typed it, never fought with it, never had the "wait, why is this null" moment that actually teaches you anything. The suggestion just... appeared, looked plausible, compiled, and you moved on. That's not learning, that's outsourcing your own competence to autocomplete and hoping nobody asks you to explain it in a code review.

Here's the honest, non-doom-and-gloom version of what to actually do about it: use the tools, for sure, they're not going anywhere and fighting that is a losing battle. But treat every AI suggestion like a pull request from a very fast, very confident junior dev who's never met your codebase. Read it. Question it. Ask yourself if you could've written that yourself, or explained why it's wrong if it is wrong. The moment you stop being able to tell the difference between "I understand this" and "this looks right," you've quietly become the high-level puppet from Episode 1 again, just with extra steps and a monthly subscription.

Episode 6: A Few Honest Tips for Not Losing Your Mind in This Industry

Alright, less roasting now, more actual advice, because I do genuinely want you to do well out there, eh.

Learn one thing below your comfort zone every few months. Doesn't have to be a whole language — read one systems paper, build one tiny project in C, sit through one lecture on how TCP actually handshakes. Small, consistent trips downward keep the muscle alive.

Ask better questions before you ask more questions. Ten minutes with the actual docs saves you two days of guessing, and it makes the people who could help you actually want to.

Don't chase every shiny framework that trends for a week. Half of them are gone in a year, the fundamentals under them never expire. Being the person who still knows how HTTP actually works in five years is worth more than being first to try whatever's hot this month.

Find your people. A good, slightly grumpy senior who'll actually review your code properly is worth more than a hundred YouTube tutorials. Buy them a coffee sometime, seriously, it goes further than you'd think.

And take care of yourself while you're at it. I wasn't kidding about the rough patch earlier — burnout is real, it sneaks up quiet, and no amount of clever pointer arithmetic fixes a person who's running on empty. Rest counts as progress too, don't let anyone tell you otherwise.

Episode 7: The Code of Conduct in Real Communities

Last one, and it's less technical, more about how you survive rooms full of people smarter than you, which — good news — is most rooms if you're doing this right.

Old-timers in strong communities have a reputation for being a little mean, and honestly, most of the time it's earned mean, not random mean. Show up with "my script doesn't work, help" and zero effort behind it, and you'll get ignored or roasted, and that's actually correct behaviour from them, not cruelty.

A good question respects the other person's time, because you respect your own. That means: the actual context and what you're trying to accomplish, the exact error log in text — not a phone screenshot of a monitor, we can all see the reflection of your ceiling fan — and a real list of what you've already tried and why it didn't work.

Show up having actually opened the docs, actually narrowed down the problem, and gotten stuck on something genuinely interesting — and people will help you with real enthusiasm, sometimes more than you expected. That's not luck. That's just how real engineering relationships get built, one well-asked question at a time.

Anyway. Good to be back, eh. This industry's a weird one — it'll humble you, ghost you, and occasionally make you cry over a missing semicolon at 2am, but it's also full of genuinely good people who'll help you out for nothing more than a well-asked question and a bit of respect for their time. You're doing better than you think you are. Go build something, break it, learn why, and I'll catch you in the next one. Take care of yourselves out there, for real.

Reinvention Is a Practice: Staying Open to What Comes Next

Thu, 06 Aug 2026 12:17:46 +0000

Lately, I have been thinking about change.

Not the dramatic kind where you wake up one morning, abandon your entire life and announce a new identity to the world. Rather, the gradual process of recognising that a version of you has served its purpose, and that it may be time to become someone slightly different.

When I look back at my life, I can see several versions of myself.

There was the young developer learning how to code, spending long hours trying to understand why things worked the way they did. There was the engineer wrestling with Docker until containers, networks and deployment pipelines finally stopped feeling like dark magic. There was the blockchain developer learning an entirely new ecosystem during the NFT wave. Now there is the engineer and business owner trying to understand what it means to build in the age of AI.

Each version required something different from me.

New skills. New habits. New ways of thinking.

More importantly, each one required me to accept that what had brought me this far might not be enough to carry me forward.

That is perhaps the most uncomfortable part of reinvention.

The Humility of Becoming a Beginner Again

There is a particular kind of discomfort that comes with learning something new.

You go from feeling competent to feeling completely lost. Concepts that other people discuss casually sound foreign. Simple tasks take hours. Progress is difficult to measure, and there are moments when you wonder whether the effort is worth it.

I remember the long hours I spent learning Docker.

At the time, it did not feel like some grand career investment. It mostly felt like confusion, poorly written configuration files and an unreasonable number of browser tabs. There were evenings when I understood less at the end than I thought I had understood at the beginning.

Eventually, things clicked.

That knowledge helped me thrive in later roles. It made me more useful during infrastructure changes and better equipped to understand the systems around the software I was building. It gave me the confidence to move beyond writing code and think more deeply about how software is deployed, operated and maintained.

The effort repaid itself many times over.

That has been true of most valuable things I have learned. The rewards rarely arrive at the same time as the discomfort. At first, you only experience the cost. The late nights, the confusion and the repeated failures are immediate. The benefits reveal themselves later, often in situations you could not have predicted.

Knowledge compounds quietly.

One skill makes the next one easier to learn. A difficult project gives you pattern recognition for the next challenge. A season of confusion becomes the foundation for decisions that later appear instinctive.

From the outside, that can look like talent.

From the inside, it feels more like accumulated struggle.

Learning to Move With the World

Technology has given me little choice but to become comfortable with change.

When blockchain and NFTs became a major frontier, I had to learn how that world worked. It meant understanding new tools, architectures and assumptions about ownership, payments and digital assets.

That wave eventually cooled, as waves tend to do.

But the knowledge did not disappear with the hype. The experience broadened how I understood financial systems and emerging technology. It also taught me something more important: I could enter an unfamiliar space, endure the confusion and eventually become competent within it.

Now we are in the AI era, and I find myself adapting again.

The tools are changing quickly. The way software is written is changing. Work that once took days can sometimes be completed in hours, but that speed introduces new questions around judgment, quality and responsibility.

I could resist it. I could insist that the methods that worked for me before should continue working forever.

But the world is under no obligation to preserve the conditions under which I became successful.

Standing still does not protect you from change. It only removes your ability to influence how change affects you.

I have noticed that some of my older and more successful colleagues are remarkably open to new ideas. They do not respond to every development with insecurity or dismissal. They ask questions. They test things. They are willing to admit that someone younger or less experienced may understand an emerging field better than they do.

That openness seems to be a common thread among many of the successful people I know.

They do not confuse experience with completion.

Being good at something today does not exempt you from learning tomorrow.

Firing Myself From the Work I Know

Running a business has introduced a different kind of reinvention.

As a developer, my instinct is to solve problems by building things. When something needs to be fixed, I want to open my laptop, inspect the code and handle it myself. Coding is familiar. It gives me a sense of control and the satisfaction of knowing that I can personally move something forward.

But a business cannot grow around the founder’s need to remain involved in everything.

Someone once advised me to fire myself every day.

The first time I heard it, it sounded slightly aggressive. Over time, I began to understand the wisdom in it.

The goal is not to make yourself useless. It is to stop being the permanent bottleneck.

Every time I build a system, document a process, delegate responsibility or allow someone else to take ownership, I am firing myself from a role the business should no longer depend on me to perform.

That sounds simple in theory. In practice, it can be deeply uncomfortable.

It is difficult to release work you know you can do well. Delegation requires trust. It requires patience when someone approaches a problem differently from how you would. Sometimes it means accepting that another person may eventually become better at that work than you are.

Holding on to every task also comes at a cost.

The more time I spend coding every feature, reviewing every small decision and solving every immediate problem, the less time I have to think about where the business is going.

My role has to evolve.

I have to think about strategy, partnerships, positioning, sales and the kind of company we are trying to become. These responsibilities do not always offer the immediate satisfaction of shipping a feature, but they are increasingly where I can create the most value.

Growth sometimes requires leaving behind the work that once made you feel valuable.

That is its own form of reinvention.

Letting Go Outside of Work

Change is not only necessary in careers and businesses.

Sometimes the habits that need to be reconsidered are personal.

There was a time when almost every weekend needed to involve going out. There was always somewhere to be, someone to meet or another loud room to enter. It was fun, until parts of it stopped being fun and continued mostly because that was what weekends had come to mean.

Lately, I have been embracing a quieter life.

For now, at least.

I am learning to enjoy my own company without treating solitude as an empty space that needs to be filled. I am becoming more intentional about how I spend my time and which habits genuinely leave me feeling restored.

This has not meant withdrawing from life. In some ways, it has created space for different experiences.

During a recent solo trip to Diani, I decided to try kitesurfing.

There is something humbling about picking up a new sport as an adult. You do not have the luxury of pretending to be naturally competent. The wind does not care about your career, confidence or carefully constructed sense of dignity. You fall, struggle, get up and try again.

I enjoyed it.

Not because I was immediately good at it, but because I was not.

It reminded me of the pleasure of entering an experience without needing to perform expertise. Of allowing curiosity, rather than competence, to lead.

I would like to become better at it over time. Not urgently, and not because every hobby must become a measurable achievement. Simply because there is something meaningful about giving yourself new worlds to grow into.

Discomfort Is Not Always a Warning

We often interpret discomfort as evidence that something is wrong.

Sometimes it is. There are situations, relationships and environments that should be left rather than endured.

But discomfort can also mean that an old identity is being stretched.

Learning exposes what we do not know. Delegation reduces our control. A quieter life feels unfamiliar when we have grown accustomed to noise. Starting a new sport reminds us that adulthood offers few opportunities to be visibly bad at something.

The instinct is often to retreat into what is familiar.

Familiarity, however, can become a very comfortable cage.

Some of the most meaningful changes in my life began with periods I would not have chosen for myself. They required uncertainty, patience and the temporary loss of confidence that comes with moving beyond what you already understand.

Looking back, I do not regret the discomfort.

I regret some of the moments when fear made me delay it.

A Letter to the Version of Me Who Feels Stuck

Perhaps this is partly a letter to myself.

A reminder to return to when motivation is low, the future feels uncertain or the work of becoming someone new feels heavier than remaining where I am.

I want to remember that I have done this before.

I learned to code when I did not know how.

I learned infrastructure when the concepts felt impossibly complicated.

I entered blockchain when the ecosystem was unfamiliar.

I am learning to build differently in the age of AI.

I am learning to lead a business rather than simply work inside one.

I am learning to release habits, roles and versions of myself that no longer serve the person I am trying to become.

None of those transitions has been perfectly planned.

Most began with a mixture of curiosity, necessity and discomfort. The confidence usually arrived after I started, not before.

That may be the lesson worth keeping.

You do not need to feel fully prepared for the next version of your life. You only need enough humility to admit that change is necessary and enough courage to take the next step.

Reinvention does not always require a dramatic announcement.

Sometimes it is learning a new tool after work.

Sometimes it is trusting someone else with a responsibility you once carried alone.

Sometimes it is declining another loud weekend and choosing rest.

Sometimes it is standing on a beach in Diani, attached to a kite, being dragged through the water while discovering that you are still capable of surprising yourself.

The world will continue changing.

So will the work.

So will the people around us.

The question is not whether change will arrive. It is whether we will remain open enough to move with it.

I hope I do.

I hope I remain curious enough to explore new frontiers, disciplined enough to endure the uncomfortable parts and humble enough to become a beginner as many times as life requires.

Because perhaps reinvention is not about becoming an entirely different person.

Perhaps it is about refusing to believe that the person you are today is the only person you are capable of becoming.

GraphQL vs REST - Which One Should You Really Use?

Tue, 04 Aug 2026 17:28:59 +0000

For years, REST APIs have been the standard.

Then GraphQL came in with promises like:

“Fetch exactly what you need”
“Reduce API calls”
“More flexible APIs”

But here’s the reality:

GraphQL is not a replacement for REST.
It’s a different trade-off.

Let’s break it down — with real code you can run.

🧠 What is REST?

REST is a resource-based API design.

You expose endpoints like:

GET /users/1
GET /users/1/orders

Each endpoint returns fixed structure data.

⚙️ REST API — Fully Working Go Example

👉 Save as rest.go

package main

import (
"encoding/json"
"log"
"net/http"
)

type User struct {
ID    int    `json:"id"`
Name  string `json:"name"`
Email string `json:"email"`
}

func getUserHandler(w http.ResponseWriter, r *http.Request) {
user := User{
ID:    1,
Name:  "John",
Email: "*Emails are not allowed*",
}

w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(user)
}

func main() {
http.HandleFunc("/users/1", getUserHandler)

log.Println("REST server running on http://localhost:8080")
log.Fatal(http.ListenAndServe(":8080", nil))
}

▶️ Run it

go run rest.go

📡 Call API

curl http://localhost:8080/users/1

📦 Response

{
  "id": 1,
  "name": "John",
  "email": "*Emails are not allowed*"
}

🧠 What is GraphQL?

GraphQL is a query-based API system.

Instead of multiple endpoints:

You use a single endpoint
Client decides what data it needs

⚙️ GraphQL API — Fully Working Go Example

👉 Save as graphql.go

Step 1: Install dependency

go mod init graphql-example
go get github.com/graphql-go/graphql

Step 2: Full working code

package main

import (
"encoding/json"
"log"
"net/http"

"github.com/graphql-go/graphql"
)

type User struct {
ID    int    `json:"id"`
Name  string `json:"name"`
Email string `json:"email"`
}

var userData = User{
ID:    1,
Name:  "John",
Email: "*Emails are not allowed*",
}

func main() {

// Define User type
userType := graphql.NewObject(graphql.ObjectConfig{
Name: "User",
Fields: graphql.Fields{
"id": &graphql.Field{
Type: graphql.Int,
},
"name": &graphql.Field{
Type: graphql.String,
},
"email": &graphql.Field{
Type: graphql.String,
},
},
})

// Root query
rootQuery := graphql.NewObject(graphql.ObjectConfig{
Name: "Query",
Fields: graphql.Fields{
"user": &graphql.Field{
Type: userType,
Resolve: func(p graphql.ResolveParams) (interface{}, error) {
return userData, nil
},
},
},
})

schema, err := graphql.NewSchema(graphql.SchemaConfig{
Query: rootQuery,
})
if err != nil {
log.Fatal(err)
}

// GraphQL handler
http.HandleFunc("/graphql", func(w http.ResponseWriter, r *http.Request) {
var params struct {
Query string `json:"query"`
}

err := json.NewDecoder(r.Body).Decode(&params)
if err != nil {
http.Error(w, "invalid request body", http.StatusBadRequest)
return
}

result := graphql.Do(graphql.Params{
Schema:        schema,
RequestString: params.Query,
})

w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(result)
})

log.Println("GraphQL server running on http://localhost:8080/graphql")
log.Fatal(http.ListenAndServe(":8080", nil))
}

▶️ Run it

go run graphql.go

📡 Call API

curl -X POST http://localhost:8080/graphql \
-H "Content-Type: application/json" \
-d '{"query": "{ user { name email } }"}'

📦 Response

{
  "data": {
    "user": {
      "name": "John",
      "email": "*Emails are not allowed*"
    }
  }
}

REST vs GraphQL — Visual Understanding

REST Flow

Client
  |
  |---- GET /users/1 ----------> Server
  |---- GET /users/1/orders ---> Server
  |---- GET /orders/101/items -> Server

Multiple requests ❌

GraphQL Flow

Client
  |
  |---- POST /graphql ---------> Server
        query {
          user {
            orders {
              items
            }
          }
        }

Single request ✅

⚠️ The Real Problem GraphQL Solves

REST Problem → Over-fetching

GET /users/1

Returns:

name, email, address, phone...

Even if you need only name.

REST Problem → Under-fetching

You need multiple calls to build UI.

GraphQL Solution

query {
  user {
    name
  }
}

👉 Exact data only.

⚖️ REST vs GraphQL — Honest Comparison

🧩 REST

✅ Simple
✅ Easy caching
✅ Easy debugging
❌ Multiple calls
❌ Over-fetching

🧩 GraphQL

✅ Flexible
✅ Single request
❌ Complex
❌ Hard caching

Note: REST uses native HTTP caching (like CDNs and browser headers), while GraphQL requires complex, custom caching strategies because queries are typically sent via POST.

❌ Query abuse risk

⚠️ Common Mistakes

❌ “GraphQL is always better”

No.

❌ Using GraphQL for simple CRUD

Overkill.

❌ Ignoring query complexity

Bad query:

users → posts → comments → replies → ...

💥 Performance issue

🧠 When to Use What

✅ Use REST when:

Simple APIs
CRUD operations
Strong caching needed
Easy debugging required

✅ Use GraphQL when:

Complex frontend
Aggregated data
Multiple services
Frequent UI changes

🔗 Real-World Architecture

Many companies use the GraphQL Gateway (or BFF) pattern:

Frontend → GraphQL Gateway → REST microservices

👉 GraphQL acts as an aggregation layer, allowing you to combine multiple REST responses into one, without refactoring the legacy backend.

🏁 Final Thoughts

GraphQL vs REST is not a battle.

It’s a design decision.

🎯 Key Takeaways:

REST = simple and predictable
GraphQL = flexible but complex
Both solve real problems
Choose based on use-case

🚀 Final Tip

If your API:

👉 Is simple → use REST
👉 Needs flexibility → use GraphQL

🛡️ Content Security Policy (CSP): A Complete Guide for Developers

Wed, 29 Jul 2026 18:44:08 +0000

Security is one of the most critical aspects of modern web development. Even if your code is correct, attackers may exploit vulnerabilities like Cross-Site Scripting (XSS) or Clickjacking. That’s where Content Security Policy (CSP) comes in.

This blog covers:
✅ What CSP is & how it works
✅ All major directives (default-src, script-src, img-src, etc.) explained in detail
✅ Real-world examples
✅ Best practices & common pitfalls

Let’s dive in. 🔥

⚙️ What is CSP & Why Do We Need It?

Content Security Policy (CSP) is an HTTP response header that defines where browsers can load resources (scripts, images, styles, fonts, iframes, workers, etc.) from.
Its main purpose: prevent XSS attacks by restricting execution of malicious scripts.
Without CSP, if an attacker injects a script into your page, the browser executes it blindly. With CSP, you can whitelist only trusted domains, blocking everything else.

Example CSP header:

Content-Security-Policy: default-src 'self'; img-src https://cdn.example.com; script-src 'self' https://apis.google.com;

This means:

By default, only load resources from the same origin ('self').
Allow images from cdn.example.com.
Allow scripts from self and Google APIs.

⚠️ Important:
If default-src is missing, everything is allowed, weakening your CSP.

📌 Important Directives

Here’s a breakdown of commonly used CSP directives:

🔑 `default-src`

The fallback for all other directives (if they are not explicitly defined).

Content-Security-Policy: default-src 'self';

If script-src or style-src is missing, browsers fall back to default-src. ✅

📜 `script-src`

Defines where JavaScript can be loaded from.

Content-Security-Policy: script-src 'self' https://apis.google.com;

Special values:
- 'self': allow only current domain
- 'unsafe-eval': allow eval() usage (⚠️ dangerous)
- 'unsafe-inline': allow inline scripts (⚠️ not recommended)

Better options:

Nonce → Random value per request:

<script nonce="abc123">console.log("Safe!");</script>

With CSP:

Content-Security-Policy: script-src 'self' 'nonce-abc123';

Hash → Allow only exact inline script:

<script>alert("hello")</script>

With CSP:

Content-Security-Policy: script-src 'self' 'sha256-XYZhashHere...';

✅ Nonce & Hash are safer than 'unsafe-inline'.

🎨 `style-src`

Controls where CSS can be loaded from.

Content-Security-Policy: style-src 'self' https://fonts.googleapis.com;

⚠️ Using 'unsafe-inline' allows inline styles → risky.
🔑 Instead:

Use nonce or hashes for dynamic styles.

Example:

<style nonce="abc123">.btn { color: red; }</style>

🖼️ `img-src`

Defines allowed image sources.

Content-Security-Policy: img-src 'self' https://cdn.example.com data:;

👉 data: allows base64-encoded images.

📄 `font-src`

Controls allowed font sources.

Content-Security-Policy: font-src 'self' https://fonts.gstatic.com;

🔗 `connect-src`

Defines where AJAX/fetch/WebSocket connections can be made.

Content-Security-Policy: connect-src 'self' https://api.example.com;

🎵 `media-src`

Specifies allowed sources for <audio> and <video>.

Content-Security-Policy: media-src 'self' https://media.example.com;

🏗️ `frame-src` vs `frame-ancestors`

frame-src: Controls what your app can embed in an <iframe>.

Content-Security-Policy: frame-src https://www.youtube.com;

frame-ancestors: Controls who can embed your site.

Content-Security-Policy: frame-ancestors 'none';

✅ Use frame-ancestors to prevent clickjacking.

🧩 `worker-src`

Defines allowed sources for Web Workers & Service Workers.

Web Workers: Run scripts in a separate thread (background tasks).
Service Workers: Proxy requests for offline support / caching.

Content-Security-Policy: worker-src 'self' https://cdn.example.com;

📂 `object-src`

Restricts plugins like Flash/Silverlight (legacy). Best to set 'none'.

Content-Security-Policy: object-src 'none';

📝 Reporting with CSP

Instead of enforcing, you can test with reporting only:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;

This way, violations are logged but not blocked. Useful before rollout.

💡 Real-World Example

Imagine your webapp loads:

Scripts from your domain + Google APIs
Styles from your domain + Google Fonts
Images from CDN

CSP could look like:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' https://cdn.example.com; connect-src 'self' https://api.myapp.com; object-src 'none'; frame-ancestors 'none'

This protects you from attackers injecting malicious scripts/images from untrusted domains.

🚨 Common CSP Issues Developers Face

❌ Images not loading → Forgot img-src domain.
❌ Fonts breaking → Missing font-src.
❌ Videos not playing → media-src missing.
❌ API calls failing → Missing connect-src.
❌ App not embeddable → Strict frame-ancestors.

👉 If your frontend/backend look fine but still break, check CSP first.

✅ Best Practices

Always define a strict default-src.
Avoid 'unsafe-inline' and 'unsafe-eval' unless absolutely necessary – use nonces or hashes.
Use 'self' wherever possible.
Test with Content-Security-Policy-Report-Only before enforcing.

📌 Conclusion

CSP is not just another header—it’s a powerful security shield 🛡️ for your apps.
The right configuration prevents XSS, clickjacking, and data injection while keeping performance intact.

👉 The bottom line: CSP = Control + Security + Peace of Mind.

build, extract, refactor

Tue, 28 Jul 2026 12:05:50 +0000

Towards the midpoint of last year, I rediscovered one of the developers I found when I started my journey - Mark Tellez. I'll admit, back then I was arrogant and didn't take what he was doing in those old videos seriously, and then he just went off the map.

In his livestreams he'd work on either client work or a suggestion from the chat. In everything he made he kept repeating these words: ''build, extract, refactor"

He didn't just say them, no. He'd say them and explain to us what they meant in real time...

build, extract, refactor

As developers we tend to rush to componentise things from the onset - sometimes when it's not necessary. This is what build, extract, refactor is meant to address

build

Mark says just build it. Wherever you are in your project, build it. Make it work, don't worry about structure. Your first and most important job is to have it built and working.

extract

As you're building, you're going to get to a point where things become too unruly. By this point, you should have noticed a structure forming all on its own - you didn't have to pre-emptively create one.

It is at this point you then start creating your components using the structure that has presented itself.

refactor

After you have taken the lead from your project and created your components, then comes the time to refactor them.

"Don't force it, the structure will reveal itself"
~ Mark Tellez

Why build, extract, refactor?

Now you could be asking yourself; "Why bother doing this? The way I've been making components works just fine"

You wouldn't be wrong asking those questions at all.

But riddle me this; Have you ever been working on a project and you encounter an error that you can't seem to figure out where exactly it's originating from? Only for you to discover it's from a file you componentised a while ago.

You could have avoided this by employing some elements of build, extract, refactor as you will have utilised the intrinsic structure of the project and not a pre-imposed one. Because you have let the project decide, things will have connected logically and tracing of errors is not as difficult.

Conclusion

Now I am not saying this is the be all end all way of building/structuring your projects, no. I am just presenting something you could consider...

Mark wasn't available for the start of this year, he had family responsibilities to handle, I am grateful for all the knowledge he imparted on me the past few months.

To this day, I have not come across a developer who will answer your questions in real-time as he's showing why one method is better than the other. One who will take a suggestion and build that suggestion as you watch.

Thank you Mark.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Polywork and LinkedIn

JavaScript Fundamentals

Thu, 23 Jul 2026 17:20:41 +0000

JavaScript Fundamentals (Week-01): Understanding Execution Context, Scope & Closures

"When I started learning JavaScript, I could write functions and variables, but I didn't understand what actually happened behind the scenes. Questions like 'Why can an inner function access an outer variable?' or 'Why does JavaScript remember a variable even after a function finishes?' made me curious. This week, I explored three important concepts that answer these questions: Execution Context, Scope, and Closures."

Introduction

JavaScript is more than just writing variables and functions. Every time we run a JavaScript program, the JavaScript engine creates an environment to execute our code.

Understanding how JavaScript manages variables, functions, and memory is essential before moving on to advanced topics like asynchronous programming, React, or Node.js.

In this article, we'll explore:

What is Execution Context?
How JavaScript executes code
What is Scope?
Types of Scope
What is a Closure?
Why Closures are useful

What is Execution Context?

Before JavaScript executes any code, it creates a special environment called the Execution Context.

Think of it as JavaScript's workspace.

This workspace contains everything needed to execute the program:

Variables
Functions
The value of this
Scope information

Without an Execution Context, JavaScript wouldn't know where variables or functions exist.

Types of Execution Context

JavaScript creates two main execution contexts.

1️⃣ Global Execution Context (GEC)

This is created when the program starts.

There is only one Global Execution Context for each JavaScript program.

Example:

let name = "Sai";

console.log(name);

Before executing this code, JavaScript creates the Global Execution Context.

2️⃣ Function Execution Context (FEC)

Whenever a function is called, JavaScript creates a new Execution Context for that function.

Example

function greet() {
    console.log("Hello");
}

greet();

When greet() runs, JavaScript creates a Function Execution Context.

Once the function finishes, its execution context is removed from memory.

How Does Execution Context Work?

Every Execution Context has two phases.

Phase 1: Memory Creation Phase

Before executing the code, JavaScript scans the program.

During this phase:

Memory is allocated for variables.
Function declarations are stored.
var variables are initialized with undefined.
let and const are hoisted but remain in the Temporal Dead Zone (TDZ) until initialized.

Example

console.log(a);

var a = 10;

Memory created:

a = undefined

Phase 2: Execution Phase

Now JavaScript executes the code line by line.

Variables receive their actual values, and functions are executed.

var a = 10;

console.log(a);

Output

Execution Context Flow

Program Starts

        │

        ▼

Global Execution Context

        │

        ▼

Memory Creation Phase

        │

        ▼

Execution Phase

        │

        ▼

Function Call

        │

        ▼

Function Execution Context

        │

        ▼

Memory Phase

        │

        ▼

Execution Phase

        │

        ▼

Function Ends

        │

        ▼

Back to Global Context

What is Scope?

Have you ever wondered why some variables can be accessed everywhere while others cause an error?

That's because of Scope.

Definition

Scope is the area where a variable is accessible.

Simply put,

Scope decides where we can use a variable.

Why is Scope Important?

Without Scope, every variable would be accessible everywhere.

This would cause:

Variable conflicts
Difficult debugging
Security issues
Poor code organization

Scope solves these problems by limiting where variables can be accessed.

Types of Scope

Global Scope

Variables declared outside all functions belong to the Global Scope.

let company = "OpenAI";

function showCompany() {
    console.log(company);
}

showCompany();

Output

OpenAI

The variable company is accessible everywhere.

Function Scope

Variables declared inside a function are available only inside that function.

function student() {

    var name = "Sai";

    console.log(name);

}

student();

Output

Sai

Trying to access name outside the function will produce:

ReferenceError

Block Scope

Variables declared with let or const exist only inside the block {}.

{
    let city = "Hyderabad";
    console.log(city);
}

Output

Hyderabad

Outside the block:

console.log(city);

Output

ReferenceError

Lexical Scope

Lexical Scope means an inner function can access variables declared in its outer function.

function outer() {

    let message = "Hello";

    function inner() {

        console.log(message);

    }

    inner();

}

outer();

Output

Hello

This happens because JavaScript remembers where the function was created.

Scope Chain

When JavaScript cannot find a variable in the current scope, it searches the parent scope.

Current Scope

↓

Parent Scope

↓

Global Scope

↓

ReferenceError

This process is called the Scope Chain.

What is a Closure?

Closures are one of the most powerful features of JavaScript.

Definition

A Closure is a function that remembers variables from its outer function even after the outer function has finished executing.

In simple words,

A Closure allows an inner function to continue using variables from its parent function.

Why are Closures Needed?

Normally, local variables disappear after a function finishes.

Closures allow those variables to stay alive as long as another function still needs them.

This is useful for:

Data privacy
Counters
Event handlers
Module patterns
Maintaining state

Closure Example

function counter() {

    let count = 0;

    return function () {

        count++;

        console.log(count);

    };

}

const increment = counter();

increment();
increment();
increment();

Output

1
2
3

How Does This Work?

When counter() is called:

JavaScript creates count.
It returns the inner function.
Even after counter() finishes, the inner function still remembers count.

Every time increment() is called:

count increases by one.
The value is preserved because of the Closure.

Key Takeaways

✔ JavaScript creates an Execution Context before executing code.

✔ Every Execution Context has a Memory Creation Phase and an Execution Phase.

✔ Scope determines where variables can be accessed.

✔ JavaScript supports Global Scope, Function Scope, Block Scope, and Lexical Scope.

✔ Closures allow functions to remember variables from their outer scope.

✔ Closures are commonly used for data privacy, counters, and maintaining state.

Conclusion

Understanding Execution Context, Scope, and Closures changed the way I think about JavaScript. These concepts explain what happens behind the scenes whenever our code runs. Once you understand them, advanced topics like asynchronous programming, callbacks, Promises, React Hooks, and Node.js become much easier to learn.

I hope this article helped you build a stronger JavaScript foundation. If you're learning JavaScript too, feel free to share your thoughts or ask questions in the comments.

C++ Traps That Caught Me Off Guard — A Beginner's Log

Thu, 23 Jul 2026 09:28:37 +0000

Learning C++ has been a journey full of traps. Here are three I hit — hope they save you some debugging time.

🎣 Trap 1: `new[]` + `delete`(instead of `delete[]`)

Wrong Code

 int* a = new int[3];
 
 // delete a; ❌ --> undefined

class MyClass{
public:
~MyClass(){
std::cout<<"delete successfully"<<std::endl;
}
}
int main(){
MyClass* mc = new MyClass[2];
//delete mc;  ❌ -> only outputs one "delete successfully"

What Happens

C++ standard clearly states that this is undefined behavior. Relying on it is extremely dangerous — different compilers, optimization levels, and platforms may behave completely differently.

new[] + delete only calls the destructor once, while delete[] calls it for every element in the array. Using delete instead of delete[] causes resource leaks for the remaining elements.

How to Fix

 int* a = new int[3];
 
 delete[] a;  -> ✔

class MyClass{
public:
~MyClass(){
std::cout<<"delete sucessfully"<<std::endl;
}
};
int main(){
MyClass* mc = new MyClass[2];
delete[] mc; -> ✔ outputs "delete successfully" twice
}

🎣 Trap 2: `cin` + `getline` eating your input

Wrong Code

int age;
std::string name;

std::cout<<"Enter age: ";
std::cin>>age;

std::cout<<"Enter name: ";
std::getline(cin, name); // ❌ name ends up empty!

std::cout<<name<<std::endl;

What Happens

cin leaves a newline character (\n) in the input buffer, and getline reads it immediately — so it stops before you even type anything.

Why

cin >> reads the value you type but leaves \n in the buffer. getline stops reading when it encounters \n, so it grabs that leftover newline and returns an empty string.

How to Fix

std::cin >> age;
cin.ignore();    // 👈 Eat the leftover newline
std::getline(cin, name);

🎣 Trap 3: `Copy constructor` vs `copy assignment`

class FixArray{
    std::string name_;
    int* data_;
    size_t size_;
public:
~FixArray(){
        delete[] data_;
    }

    FixArray(const FixArray& other) : FixArray(other.size_, other.name_){
        std::copy(other.data_, other.data_ + size_, data_);
    }

    FixArray& operator=(const FixArray& other){
        if(this != &other){
            int* new_data = new int[other.size_];
            std::copy(other.data_, other.data_ + other.size_, new_data);
            delete[] data_;
            data_ = new_data;
            size_ = other.size_;
            name_ = other.name_;
        }
        return *this;
    } 
};

Many beginners can't tell the difference between a copy constructor and a copy assignment. Actually, it's quite simple:

// Copy constructor: creating a new object from an existing one
FixArray fa(10, "example");
FixArray fb = fa;    // 👈 copy constructor called

// Copy assignment: assigning to an already-existing object
FixArray fc(5, "other");
fc = fa;            // 👈 copy assignment called

Copy constructor — creates a brand new object as a copy of an existing one.

Copy assignment — replaces the contents of an already-existing object with another object's data.

The key difference: copy constructor builds something from nothing; copy assignment replaces something that already exists.

>These are three traps I hit while learning C++. If you're a beginner too, I hope this saves you some debugging time. Have you encountered other tricky C++ traps? Share them below!

📦 The Ultimate Guide to package.json, package-lock.json, .yarnrc, babel.config,tsconfig.json & More

Wed, 22 Jul 2026 16:56:11 +0000

Most developers use these config files daily — but few truly understand how they work, why they matter, and how small mistakes can break a project or waste hours of debugging time.

This post goes beyond definitions: we’ll explore how these files work, why they matter, best practices, and common real-world mistakes to avoid.

1️⃣ `package.json`

What it is:
The heart of any Node.js or React project.
It lists the project’s metadata, dependencies, scripts and configuration.
How it works:
Acts as the project manifest — when you run npm install, it reads the dependencies and installs them.
Important things to remember:
- Keep dependencies (dependencies) and dev tools (devDependencies) separate.
- Always update versions carefully — check changelogs when upgrading.

👉 Quick Difference:dependencies are needed to run the application in production, while devDependencies are only needed for development, testing and build processes.

Best practices:
- Define clear scripts (e.g., npm run test, npm run lint) to standardize tasks for all developers.
- Use semantic versioning (^, ~, exact versions) wisely. The versioning symbols define the range of versions allowed, and npm/yarn automatically picks the newest allowed version (unless restricted by the lockfile).
Real-world tip:
Messy or outdated package.json often causes “it works on my machine” issues, especially in CI/CD. Always commit updated files!

2️⃣ `package-lock.json` / `yarn.lock`

How they work:
Record exact package versions (including nested dependencies) used at install time.
Why they matter in CI/CD:
Without lock files, your CI pipeline might install newer versions of packages than local dev, causing unpredictable failures.
Best practices:
- Always commit lock files to version control.
- Never manually edit lock files.
- Avoid deleting lock files just to “fix” install issues — this usually hides the real problem.
Real-world mistake:
A team skips committing package-lock.json; their staging environment works, but production deploy breaks because a sub-dependency released a breaking change overnight.

🔑 Important to know:
The lockfile (package-lock.json or yarn.lock) pins the exact version after the first install. Even if your package.json allows a higher version, the lockfile keeps things stable until you explicitly update.

3️⃣ `.yarnrc` / `.npmrc`

How they work:
Customize the behavior of npm/yarn, e.g., set private registries or proxies.
Important to remember:
- Keep sensitive tokens out of versioned .npmrc / .yarnrc.
- For private registries, use .npmrc in the CI/CD pipeline or environment variables.
Best practices:
- Store per-user configs in your home directory (~/.npmrc), not in the project if they contain sensitive info.

4️⃣ `babel.config.js` / `.babelrc`

How it works:
Transforms modern JavaScript (ES6+, JSX, TypeScript) into code browsers understand.
Common mistakes:
- Missing or misconfigured presets cause build failures.
- Using incompatible Babel and Webpack versions leads to hours of confusing errors.
Best practices:
- Explicitly define presets (@babel/preset-env, @babel/preset-react) in projects.
- Keep Babel versions in sync with other tools.

5️⃣ `tsconfig.json`

How it works:
Controls TypeScript’s compiler behavior and type checking.
Critical settings:
- strict → enables full type safety.
- target → defines output JS version.
- baseUrl / paths → improve import paths and avoid ugly ../../ imports.
Best practices:
- Use strict mode in production projects.
- Align tsconfig.json with CI/CD type-check steps.
Real-world issue:
You skip strict mode to save time, ship to production, and later discover subtle type bugs that could have been caught early.

6️⃣ `.eslint.json` / `.eslintrc.js`

How it works:
Defines code linting rules — runs in editors, CI pipelines, or as pre-commit hooks.
Best practices:
- Use a shared team config or extend popular configs like Airbnb or StandardJS.
- Integrate linting into CI to prevent code quality regressions.
Real-world example:
Teams without enforced linting often waste time reviewing minor formatting issues in PRs.

7️⃣ `.prettierrc`

How it works:
Configures automatic code formatting.
Best practices:
- Run Prettier in your editor + CI pipeline.
- Use .prettierignore to exclude large generated files.

8️⃣ `.gitignore`

How it works:
Tells Git which files/folders to skip tracking (like node_modules, .env).
Best practices:
- Keep your .gitignore up to date; accidentally committing node_modules can break builds or bloat the repo.
- Check .gitignore on new clones to avoid pushing unwanted files.

💥 Why It All Matters in CI/CD

CI/CD systems rely on predictable, repeatable builds. These config files:

✅ Ensure consistent dependency versions
✅ Standardize linting and formatting
✅ Prevent committing sensitive or unwanted files
✅ Configure tools like Babel, TypeScript, Webpack correctly across environments

Without understanding them, you risk:

Broken deploys
Hard-to-debug environment differences
Hours of wasted developer time chasing “mystery” bugs

💥 Common Mistakes to Avoid
Deleting lockfiles to “fix” install errors → leads to unpredictable builds.

Ignoring Babel or TypeScript warnings → causes runtime crashes.

Not updating scripts in package.json → CI pipelines skip critical checks.

💡 Final Thoughts

Understanding these config files isn’t just “setup work”—it’s the foundation of reliable, maintainable apps. Whether you’re a frontend dev or working on CI/CD, mastering these files will save hours of debugging and make you a stronger engineer.

Coming Back to Writing - and My First Cybersecurity Project

Sun, 19 Jul 2026 11:23:26 +0000

It's been a while since I've written anything publicly. I used to be fairly active documenting what I was building as a developer, and somewhere along the way - between shipping products and then pivoting toward cybersecurity - I went quiet. This is me picking that habit back up, starting with the most honest thing I can write about: a small, beginner-level tool I just finished.

I'm not writing this to announce a launch. I'm writing it because documenting the learning is the actual point.

Where I'm At

I come from a full-stack development background - I've shipped a few SaaS products solo. Over the past several months I've been transitioning into cybersecurity, specifically working toward a SOC Analyst role. I'm doing hands-on labs on LetsDefend, going through ISC2 CC and Google Cybersecurity material, and generally trying to learn by doing rather than just collecting certificates.

One thing I noticed early: every SOC case follows a similar manual pattern. You get an IOC - an IP, a domain, a file hash - and you check it across two or three different threat intel sources by hand. VirusTotal here, AbuseIPDB there, MalwareBazaar if it's a hash. Same value, three tabs, three logins, three waits.

So as a first project bridging my dev background with what I'm learning in security, I built a small tool that does that lookup automatically.

What I Built (and What It Isn't)

IOC Enricher - paste an IP, domain, or hash, it queries VirusTotal, AbuseIPDB, and MalwareBazaar in parallel, and gives back a combined risk score with a plain-English AI summary.

I want to be upfront: this is not a novel idea. Tools like this already exist - some far more polished, built by people with actual SOC experience. I'm not claiming to have invented anything. What this project actually is: a way to force myself to touch real APIs, handle real failure cases, and understand the manual workflow well enough to automate a small piece of it.

It's a beginner project. I built it knowing that.

Live: https://ioc-enricher-abd.vercel.app/
Code: github.com/m-abdullah-06/ioc-enricher

What I Learned Building It

The stack itself was straightforward - FastAPI backend, Next.js frontend, Groq for the AI summary. Nothing exotic. The useful part was what went wrong.

MalwareBazaar, for instance, silently returned "not found" for every hash I tested - including ones I knew were malicious. My first assumption was that the hashes just weren't in their database. Turns out abuse.ch now requires an Auth-Key header on every request, and my code was getting a 401 that my error handling quietly swallowed. The tool wasn't broken - it just looked like it was working while giving me nothing.

That was the real lesson. Not the fix itself, which took five minutes once I found it, but the realization that a silent failure that looks like a valid result is worse than an obvious crash. If this were a real SOC tool and not a portfolio piece, that bug would mean telling someone a file was clean when it was never actually checked.

Why I'm Writing This Instead of Staying Quiet

I could've kept this to myself until I had something more impressive to show. But I think there's more value in documenting the beginner version honestly - partly for my own record of where I started, and partly because I know there are other people making the same dev-to-security switch who might find the process more useful than a polished result.

I'll keep building on this - bulk lookups, maybe Shodan integration, better error handling than the silent-failure lesson taught me I needed. But this version, the rough first one, is the one worth writing about.

More writeups coming as I close more SOC cases and keep building. Good to be back.

Muhammad Abdullah - learning SOC analysis, building things along the way. GitHub: m-abdullah-06

Understanding Backpropagation with micrograd — Principles, Intuition, and Pitfalls I Ran Into

Thu, 16 Jul 2026 11:48:52 +0000

I had heard about backpropagation many times, but I never really understood how it actually worked. When someone asked me what backpropagation was, all I could say was, "It's how neural networks learn… I guess?"

I'd seen the formulas, I knew the chain rule, but it always felt like there was a wall between me and true understanding.

So I spent two days reading Karpathy's micrograd project source code. It's honestly the best explanation of the core principles of neural networks I've ever come across!
👉 https://github.com/karpathy/micrograd

This post documents what I learned and how I understand it now.

Why This Post

I'd watched plenty of YouTube videos explaining backpropagation, but most of them just said:

Backpropagation is repeatedly applying the chain rule.

That's true, but for a beginner, it's basically saying nothing.
I was used to frameworks where a single line — loss.backward() — got the job done, with no idea what was actually happening under the hood.

The Key Code & What It Does

class Value:
    def __init__(self, data, _child = (), _op = "", label = ""):
        self.data = data
        self._prev = set(_child)
        self._backward = lambda: None
        self.grad = 0.0
        self._op = _op
        self.label = label
    
    def __repr__(self):
        return f"Value(data = {self.data})"

    def __add__(self, other):
        other = other if isinstance(other, Value) else Value(other)
        out = Value(self.data + other.data, (self, other), "+")

       def _backward():
            self.grad += out.grad * 1.0
            other.grad += out.grad * 1.0
        out._backward = _backward
        return out

     def backward(self):

        topo = []
        visited = set()
        def build_topo(v):
            if v not in visited:
                visited.add(v)
                for child in v._prev:
                    build_topo(child)
                topo.append(v)
        self.grad = 1.0
        build_topo(self)

        for node in reversed(topo):
            node._backward()

micrograd also defines __mul__, tanh, __pow__ and other methods — they all work the same way, each attaching a different _backward note. So I'm only showing the core code here.

Try this:
a = Value(1.0)
b = Value(2.0)
n = a + b
L = n.tanh()

You'll get this result:

How It Works

When you write n = a + b, here's what happens:

A new Value instance n is created.
A _backward function is attached to n._backward() but not executed yet.
When backward() is called, it traverses the graph in reverse topological order, executing each node's _backward() one by one.

Things You Should Know

Chain Rule:
∂e/∂a = (∂e/∂c)(∂c/∂a) + (∂e/∂d)(∂d/∂a)

At first I didn't accumulate gradients in _backward() — just assigned them. That led to some serious bugs.

Imagine you write:
a = Value(2.0)
b = a + a

What do you expect?
a.grad = 2, b.grad = 1? Or a.grad = 1, b.grad = 1?

If you run it, you'll find a.grad = 1 — which is completely wrong!

    def __add__(self, other):
    other = other if isinstance(other, Value) else Value(other)
    out = Value(self.data + other.data, (self, other), "+")
    def _backward():
        self.grad = out.grad * 1.0   # self = a, other = a;
        other.grad = out.grad * 1.0  # both set a.grad = 1
    out._backward = _backward
    return out

Here's another example:

Try this:
a = Value(2.0)
b = Value(3.0)
c = a + b
d = a b
e = c d

What are a.grad and b.grad this time?

Clearly, the gradients of a and b got overwritten!
So you MUST accumulate in _backward()!

My Confusion

For a long time I couldn't understand what def _backward() and out._backward = _backward were really doing. Sounds silly, I know.

I kept wondering: when Value c is created, out.grad defaults to 0 — how can it possibly backpropagate to find self.grad and other.grad? (Of course, back then I thought out._backward = _backward would immediately execute the _backward function 😅)

Now I finally get it:

After creating a new Value c, c._backward just stores the _backward function without running it. It only executes when backward() is called, traversing in reverse topological order.

It's a naive question that came from a naive assumption, but I hope it helps other developers who've been stuck on the same thing.

A Thought That Followed

Imagine this:
a = Value(2.0)
b = Value(3.0)
c = Value(2.0)
d = a + b
e = c + d

Do a, b, and c have their _backward executed?

Answer: All three have _backward set to lambda: None (an empty function). When backpropagation reaches them, nothing happens — their gradients have already been accumulated through the upstream path.

What I Gained

After carefully reading through Karpathy's micrograd source code, I was genuinely impressed. I'd never understood the core of backpropagation so intuitively before. Here's what I took away:

I now understand the core mechanism of backpropagation — .backward() is no longer a black box to me.
I finally truly understand what "backpropagation is just repeatedly applying the chain rule" means.
This has kicked off my deep dive into deep learning, and now I can better compare micrograd with PyTorch and modern neural network frameworks.

Closing Thoughts

Thanks for taking the time to read this. I wrote it right after going through the source code, so there may be mistakes in my understanding — corrections are very welcome.

If you're also a beginner in deep learning, feel free to reach out. I'd love to learn together with you.

If you enjoyed this post, don't forget to like, bookmark, comment, and follow! I'll be sharing my learning journey in deep learning, machine learning, backend development, and more from time to time.

Check out my Dev.to: https://dev.to/elysianx138
My GitHub will also track my learning progress: https://github.com/elysianx138

From "I Understood Nothing" to Building a RAG App

Wed, 15 Jul 2026 09:10:21 +0000

Yesterday, I took the time to go through 31 pages of my own notes on NLP, notes I had carefully created during an AI engineering course. However, I found that I understood very little of it.

It felt odd and disheartening to have written something down yet not grasp it. I initially thought the issue was with me. But that wasn't the case. The real issue was that simply reading notes does not equate to true learning. My notes were packed with information intended for a version of me that already had some understanding, and you can't develop comprehension just by rereading a summary. So, I decided to change my approach. Instead of reading, I had the concepts explained to me one question at a time, starting from the basics, using only simple examples. No technical terms were permitted until I had proven I could understand them.

By the end of the day, I had reconstructed the four main concepts of practical NLP from the ground up, and I used them to create a functioning app that answers questions based on my own notes. Here's the complete journey, with the same examples that finally helped me understand, along with the code for each step so you can follow along.

Start with the dumbest possible question

Imagine you want a computer to sort emails into "spam" and "not spam." Here's the catch: the computer has never read a word in its life. The only thing it can do, the only thing it has ever been able to do, is math on numbers.

So before it can sort a single email, one problem comes first: the words have to become numbers. That sentence turned out to be the foundation of everything. All of this branch of NLP is just one job: turn text into numbers without losing the meaning that matters.

My first instinct was to turn each letter into a number. It's a reasonable guess, and it's actually how computers store text underneath. But it captures spelling, not meaning. "win" and "bin" look almost identical as numbers, yet mean totally different things. The meaning of an email lives in its words, not its letters.

Bag of Words: count, don't spell

So we work with whole words. Take three emails:

"win money now"
"money money money"
"see you tomorrow"

List every distinct word (that's the vocabulary), give each a column, and for each email count how many times each word appears. "win money now" becomes 1, 1, 1, 0, 0, 0. "money money money" becomes 0, 3, 0, 0, 0, 0. Suddenly every email is a row of pure numbers, and a computer can compare them.

scikit-learn does exactly this in three lines:

from sklearn.feature_extraction.text import CountVectorizer

emails = ["win money now", "money money money", "see you tomorrow"]

vectorizer = CountVectorizer()
X = vectorizer.fit_transform(emails)

print(vectorizer.get_feature_names_out())  # the vocabulary (the columns)
print(X.toarray())                         # each row = one email as word-counts

That's it. That's the intimidating-sounding "Bag of Words." I had read about it and bounced off it; here I did it by hand in two minutes, then in three lines of code.

It's called a bag for a reason, and the reason is also its flaw. Imagine tossing a sentence's words into a paper bag and shaking it. You still know which words are inside and how many, but the order is gone. "win money now" and "now win money" produce the identical row. Usually harmless. But consider "dog bites man" versus "man bites dog": same three words, one is a boring Tuesday and the other is front-page news. To Bag of Words they're identical. That weakness is exactly why fancier methods had to be invented later.

TF-IDF: not all words deserve equal weight

Bag of Words has a second problem: it treats every word as equally important. The word "the" is in nearly every email, so knowing an email contains "the" tells you nothing. Meanwhile a rare word like "viagra" is a screaming signal. Yet Bag of Words counts them the same.

TF-IDF fixes this with two dials multiplied together:

TF (term frequency): how often a word appears in this one email. If a message says "money money money money," it's clearly about money. Repetition means importance.
IDF (inverse document frequency): how rare the word is across the whole pile, measured by how many separate emails contain it. Common word → tiny score. Rare word → big score. ("Inverse" just means flipped: more documents, smaller score.)

Multiply them, and something beautiful happens. Take "the": it appears a lot (high TF) but it's everywhere (near-zero IDF), so high × almost-zero ≈ zero. The word silences itself. Nobody handed the computer a list of words to ignore. The math removed the filler on its own. Meanwhile "viagra" in a spam email is repeated (high TF) and rare (high IDF), so it lights up bright.

Same API, one word swapped:

from sklearn.feature_extraction.text import TfidfVectorizer

vectorizer = TfidfVectorizer()
X = vectorizer.fit_transform(emails)

print(X.toarray().round(2))  # same shape, but now weighted by rarity

I tested the idea on "win win win money the the" and correctly predicted "win" would score highest, repeated and rare, while "the" collapsed to nothing. The method had taught me to think the way it thinks.

Embeddings: giving words a place on a map

Both methods above share a blindness: to them, "money" and "cash" are as unrelated as "money" and "banana." Each word is just its own separate column, with nothing connecting them. They have no concept that two different words can mean nearly the same thing.

Embeddings fix this with one gorgeous idea: put every word on a map of meaning. Picture a giant map where each word is a dot. We place words that mean similar things near each other, and unrelated words far apart. "cash" sits right next to "money"; "banana" is way over by "apple." A word's coordinates on that map, written as numbers, are its embedding. "king" lands closer to "queen" than to "bicycle," because the map is organized by meaning.

But how does a computer that can't read decide where to put each word? Through the company a word keeps. It reads millions of sentences and notices that "money" and "cash" are both surrounded by the same neighbors: borrow, pay, bank, withdraw. Same company, same neighborhood. "banana" keeps different company (eat, peel, ripe, fruit), so it lands far away. The computer never knows what any word means; it just matches patterns of context. (The real map isn't flat with two directions; it has hundreds, which is why an embedding is a long list of numbers. The idea is identical: close = similar, far = different.)

A pre-trained model hands you those coordinates directly:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
vecs = model.encode(["money", "cash", "banana"])

print(vecs.shape)  # (3, 384) → three words, each a dot with 384 coordinates

The kicker: it's not only single words. A whole sentence, or a whole note, can become a dot too, and that's the hinge the entire next step swings on.

RAG: I accidentally invented it

Here's where it all paid off. Imagine every note in my wiki is a dot on the meaning map. Then I type a question, and that question becomes a dot on the same map. To find the note that answers it, I just grab the nearest dots.

That's the entire idea behind RAG (Retrieval-Augmented Generation):

Turn the question into a dot (embed it).
Find the nearest note-dots on the map (retrieval).
Hand those notes to a language model and say "answer using only these."
The model writes an answer grounded in my actual notes instead of guessing.

Most people learn RAG by copying a tutorial and have no idea what's happening underneath. I arrived at it by reasoning, which meant I understood every layer before I wrote a line of code.

Synapse: making it real

So I built it, in a Jupyter notebook, and named it Synapse, because a synapse is the connection between two neurons, which is exactly what embeddings do: connect related notes by meaning.

The pipeline is just the four ideas above, in order.

1. Load every note:

from pathlib import Path

WIKI = Path("path/to/my/wiki")
notes = [{"path": str(f), "text": f.read_text(encoding="utf-8")}
         for f in WIKI.rglob("*.md")]

print(f"Loaded {len(notes)} notes")

2. Embed each note into a dot on the map:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode([n["text"] for n in notes])  # shape (N, 384)

3. Retrieve the nearest notes to a question:

from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

question = "what is the difference between stemming and lemmatization?"
q_emb = model.encode([question])

scores = cosine_similarity(q_emb, embeddings)[0]  # "near = similar", as a number
top = np.argsort(scores)[::-1][:3]                # the 3 closest notes

4. Generate a grounded answer from those notes:

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from your environment

context = "\n\n---\n\n".join(notes[i]["text"] for i in top)
prompt = f"""Answer the question using ONLY the notes below.
If the answer isn't in the notes, say you don't know.

NOTES:
{context}

QUESTION: {question}"""

resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=500,
    messages=[{"role": "user", "content": prompt}],
)
print(resp.content[0].text)

That last instruction ("if the answer isn't in the notes, say you don't know") is the anti-hallucination guard. It's the difference between a toy and something you can trust.

I asked it: "What's the difference between stemming and lemmatization?" It pulled up exactly the right notes and wrote an answer that reproduced my own comparison table: the tools, the "studies → studi" example, all of it. Not from the model's training. From my brain, retrieved and read back to me.

What actually made it click

An hour into all this, I'd gone from "I understand nothing" to deriving RAG on my own. The lesson wasn't really about NLP. It was about how to learn:

Reading is not understanding. I'd mistaken having notes for having knowledge. The fix was active discovery: being asked a question and having to reach for the answer, one small step at a time, every abstract idea anchored to something concrete (a paper bag, a map, a spam email). And then building, because nothing reveals what you don't understand faster than making it run.

If you're staring at material that won't stick, try this: stop reading it. Have it asked of you instead. Start from the dumbest possible question and refuse to move on until each piece genuinely makes sense. You can get further in a day than you'd believe.

Next up for Synapse: chunking notes for sharper retrieval, citing its sources, a real frontend, and a local-model version. The journey continues. I'll write that one up too.

How to Start Docker for Beginners

Wed, 15 Jul 2026 00:54:55 +0000

What's Docker

Docker is a containerization platform that packages applications with all dependencies into portable utils called containers.

Learn the foundational concepts of `Docker`

Core concepts:

Image: A read-only blueprint containing app code,libraries,and environment settings.
Container: A running instance of an image.
Dockerfile: Script defining how to build an image.
Volume: Persistent storage outside the container lifecycle.
Network: Enables communication between containers.

Example: Building and Running a Container

FROM node:18
WORKDIR /app
COPY package.json ./
RUN npm install
COPY .
EXPOSE 3000
CMD ["npm", "start"]

docker build -t my-node-app

docker run -p 3000:3000 my-node-app

Managing Multi-Container Apps with Docker Compose

version: '3'
services:
 app:
   build:
   ports:
     - "3000:3000"
   depends_on:
     - mongo
 mongo:
   image: mongo
   volumes:
     - mongo-data:/data/db
volumes:
 mongo-data:

RUN with:

docker-compose up

Best Practices

Use .dockerignore to exclude unnecessary files(e.g.,.git,node_modules).
Avoid :latest tags;pin versions for stability.
Run containers as non-root for security.
Use multi-stage builds to reduce image size.
Store secrets in .env files or Docker secrets, not in images.

When to Use Docker

[Y] Consistent dev/prod environments
[N] Small static sites or quick scripts where setup overhead outweighs benefits.

Next Steps

Learn Docker networking(bridge, host, overlay)for container communication.
Explore Docker volumes for persistent data.
Integrate Docker into CI/CD pipelines for automated builds and deployments.

With these fundamentals, you can confidently containerize, run, and manage applications in any environment.

What's the Future of Coding Practice Platforms in the AI Era?

Fri, 10 Jul 2026 16:47:13 +0000

We all seem to agree on one thing: the best way to learn a new language or framework today is to build real projects. Tutorials and exercises only take you so far.

But that got me thinking about platforms like LeetCode, HackerRank or Exercism, the ones built around coding challenges, algorithms, and exercises.

In a world where AI can solve most of those challenges in seconds, what's their future?
Are they still relevant as learning tools? Or are they slowly becoming obsolete replaced by project-based learning and AI-assisted exploration?

I'm also curious about the hiring side: companies have used LeetCode-style interviews for years. Does that change when candidates can just... ask AI?

A few questions I'd love your take on:

Do you still use platforms like LeetCode or Exercism to practice?
Do you think algorithm challenges are still a valuable way to learn in 2026?
Should these platforms reinvent themselves and if so, how?

Would love to hear from people who've used these platforms recently, or who hire developers and still rely on this kind of assessment. 👇

First miniconference on raytracing and GPUs as concepts in computer graphics

Sat, 04 Jul 2026 06:33:38 +0000

Yesterday, I attended a mini conference at zone01 Kisumu that focused on ray tracing, GPUs, and the technology behind modern computer graphics.

Before the session, I had heard these terms many times but didn't fully understand how they worked together. The talks helped me connect the dots.

Some of the key things I learned include:

What ray tracing is: An advanced rendering technique that simulates how light behaves to create realistic shadows, reflections, and lighting.

Why GPUs are important: Unlike CPUs, GPUs are designed to process thousands of calculations simultaneously, making them ideal for graphics rendering and other highly parallel tasks.

How ray tracing uses GPU power: Since ray tracing requires a huge number of calculations, modern GPUs accelerate the process, making real-time rendering possible in games and other applications.

Real-world applications: Beyond gaming, ray tracing is used in animation, architecture, engineering, product design, and visual effects.

One of the biggest takeaways for me was seeing how computer science concepts like parallel processing have practical applications in creating realistic digital experiences.

As someone still learning and growing as a developer, I enjoyed the session as it was a great learning opportunity for me that introduced me to concepts I didn't know about.

A big thank you to the organizers and speakers at Zone01 for sharing their knowledge. Looking forward to attending more technical sessions like this.

My First Global Hackathon: What I Learned Building Moonsu Link

Sat, 04 Jul 2026 02:55:05 +0000

This was my first global hackathon, with 500+ participants from around the world, and although I didn’t win, I’m honestly proud of how much I learned from the experience.

I worked on Moonsu Link, a project I care about deeply. It wasn’t just about building something technical. It was about trying to solve a real problem and pushing an unfinished idea all the way into something more complete, more usable, and more meaningful.

Like many hackathon projects, Moonsu Link came with its own challenges. There were moments of uncertainty, moments where the product needed more structure, and moments where it would have been easy to slow down or stop. But I kept going because I believed the idea was worth finishing.

The Power of Collaboration & Community

What made this experience special was the teamwork. Building with others, sharing ideas, dividing responsibilities, and trying to keep the momentum alive taught me a lot about collaboration. A hackathon is not just about code. It is also about communication, trust, iteration, and resilience.@alchemycodes @yvesdylane

I also learned that progress matters, even when the final result is not a win. Finishing something, improving it, and learning through the process can be just as valuable as a prize.

One of the things I’m happy about is that I received a badge from the DEVPost community. That recognition means a lot to me because it reflects the effort, growth, and persistence behind the project.

Key Takeaways

This hackathon reminded me that:

First attempts are still valuable – Every expert was once a beginner. Starting is half the battle.
Teamwork makes a huge difference – Bouncing ideas off others and distributing tasks accelerates growth.
Challenges are part of the process – Friction and bugs are inevitable; navigating them builds engineering maturity.
Not winning does not mean losing – The knowledge and connections gained are permanent assets.
Learning and finishing count – Shipping a complete product cycle is a victory in itself.

Moving Forward

Moonsu Link may not have taken the top prize, but it gave me something important: experience, confidence, and a stronger mindset for the next challenge.

I’m grateful for the opportunity, grateful for the people I worked with, and grateful that I chose not to give up.

Have you ever participated in a global hackathon? What was your biggest takeaway from your first dev challenge? Let's connect in the comments below!

The Reality of Roadmaps 🗺️

Tue, 30 Jun 2026 09:00:00 +0000

Do roadmaps actually help people learn?

I am not sure.

Because the first time I saw one, it did the exact opposite.

I remember opening a DevOps roadmap at roadmap.sh and seeing Linux, Networking, AWS, Docker, Terraform, Kubernetes, CI/CD, Security...

The list just kept going.

Instead of feeling motivated, I felt overwhelmed.

I closed all the tabs, shut down my laptop, and went to sleep.

I am serious.

It looked less like a learning path and more like a university degree.

What made it worse was that I went back the next day and tried again.

Same feeling.

Surely there had to be a simpler version somewhere.

So I did what most people do.

I went looking for a better roadmap.

Instead, I found more roadmaps with different layouts, orders, and opinions.

One said to learn Docker before Kubernetes.

Another said the opposite.

One started with Python.

Another skipped it entirely.

I kept searching for the version that would finally make sense.

What I found instead was more confusion.

At some point, I stopped and asked myself an honest question.

Was I actually learning anything?

The answer was no.

I was researching how to learn without doing any learning.

Collecting roadmaps as if they were going to do the learning for me.

That realisation was uncomfortable.

Because it meant the problem was not the roadmap.

It was what I expected the roadmap to do.

There are AWS concepts that took me weeks to understand.

There are things I thought I understood until I tried using them.

There are topics I ignored and had to come back to later.

None of that ever shows up on a roadmap.

The roadmap only shows the clean version of the story.

The finished version.

The version that makes sense after everything has already happened.

Roadmaps show what a field looks like when you zoom out.

They do not show what learning feels like when you are inside it.

I still visit roadmap.sh.

I still think roadmaps are useful.

But I no longer expect them to remove the messy part of learning.

This roadmap feels real to me.

If you enjoy reflections like this, you can subscribe to the newsletter.

You can follow my work and projects on Twitter, LinkedIn, GitHub, and YouTube, where I share what I am building and learning along the way.

Thank you for reading.

Coder Legion - Recent posts tagged learning

My AI Coding Project Files: What You Can Borrow

1. Pick the problem—not the whole setup

2. Project rules: what should the agent leave alone?

3. A task procedure: what am I asking for now?

4. A checkpoint: where did I stop?

5. A handoff: what does a new session need?

6. A journal: why did I make that choice?

7. The supporting files: useful when you need them

8. The older files show how the setup grew

9. Adapt the format to your tool

10. Leave room for experiments

I’m Still Learning AI Coding: The Rules and Workflows Helping Me Find My Way

1. Decide what I want before asking the agent to build it

What changed between July and October

2. My rules guide the agent—not my imagination

One example: keeping the project small enough for me

3. Give a smaller task a clear purpose

4. Leave myself a way to come back

The kind of note that helps me resume

5. Ask for help, read the docs, and keep adjusting

6. Coding experience helps—but the tool still needs learning

I do not think you need the most expensive tool to begin

7. Experimentation is a reason to build—not a consolation prize

A personal project can be a place to play

If you want to try this, start with one file

How Adobe Firefly and Copilot Taught Me to Prompt for Code (Part 1)

Fighting the "Default Weight" (Why Lazy Prompts Fail)

How Firefly Actually Works: Parameter Pipelines & Edge Copilot

The Pre-Editing Experiments: Diagnosing Cross-Attention Bleed

Input Sanitization: The 1:1 Cutout Breakthrough

The Takeaway (And What's Next in This Series)

List Of Machine Learning (ML) Models

How Online Learning Can Help Coaching Institutes Go Digital

Personal Branding for Developers: Make Your Growth Visible

Give people a reason to remember you

Community shows me where to grow

Connections travel further than we expect

Why I'm starting Opportunity Map

Start with one honest contribution

Learning `just`: A Practical Task Runner

My first thought was Make

The just version

A few things I liked about just

No .PHONY

No tab problem

just --list

But is just actually better than Make?

There are other options too

So, am I switching to just?

A Beginner’s Guide to Git and GitHub: From Installation to Your First Push

1. What Is Git and Why Does It Matter?

Why is Git important?

2. Setting Up Your Environment

Step A: Install Git Bash

Step B: Configure Your Identity

3. Secure Your Connection: Setting Up SSH Keys

Step 1: Generate Your SSH Key

Step 2: Add Key to the SSH Agent

Step 3: Add the Public Key to GitHub

Step 4: Test the Connection

4. Navigating and Creating Your Project

5. Tracking Changes (The Core Workflow)

6. Pushing Code to GitHub

Step A: Create the Repository on GitHub.com

Step B: Connect and Push

7. Pulling Code from GitHub

📚 Resources to Keep Learning

Conclusion: Congratulations! You've just set up a professional dev workflow. Git can be tricky at first, but keep practicing and it will become second nature. If you ran into any issues, drop a comment below and let's help each other out!

Building CodeHarborHub: My Journey Toward Open-Source Developer Education

Introduction

Why I'm Building CodeHarborHub

What I'm Working On

Technology and Development

Why Open Source Matters

What's Next?

Let's Connect

Use AI to Get Smarter, Not Lazier

️ The long way is where the learning happens

⚡ AI is the ultimate shortcut

The `just` version

A few things I liked about `just`

No `.PHONY`

`just --list`

But is `just` actually better than Make?

So, am I switching to `just`?

1️⃣ `:is()`

2️⃣ `:not()`

3️⃣ `:where()`