DEV Community: Mayank Roy

The Bug Wasn't Where I Thought It Was

Mayank Roy — Tue, 14 Jul 2026 18:32:56 +0000

Today reminded me why debugging is one of the most valuable skills a developer can have.

I deployed one of my projects expecting everything to work smoothly. Instead, multiple routes started breaking in production. My first instinct was that the routing itself was the problem, so I began fixing route definitions and checking navigation logic.

Every time I fixed something, another error appeared.

For hours, it felt like I was playing whack-a-mole with bugs. I reviewed components, deployment settings, API calls, environment variables, and server configuration. Nothing seemed to explain why the application worked locally but failed after deployment.

Eventually, I discovered I needed fallback routes for client-side routing, which resolved part of the issue. That felt like the answer... until more requests kept failing.

The real culprit turned out to be my _Axios _configuration.

A small mistake in how my API client was configured caused requests to fail in production, which made it appear as if my routes were broken. The routing wasn't the primary issue—it was simply exposing another configuration problem underneath.

This experience reinforced a few lessons:

The first visible error isn't always the root cause.
Production environments expose issues that localhost can hide.
Debugging is a process of forming hypotheses, testing them, and eliminating possibilities.
Understanding why something breaks is far more valuable than finding a quick fix.

Writing features is exciting, but debugging teaches you how your application actually works. Every frustrating bug is an opportunity to understand your stack a little more deeply.

Today didn't add a new feature to my project.

It made me a **better **developer.

Building a Memory-Driven AI Tutor in 4 Days with Cognee

Mayank Roy — Mon, 06 Jul 2026 13:01:04 +0000

How we designed Continuum — an AI tutor that remembers students, adapts its teaching strategy, and improves over time

Most AI tutors are good at answering questions. Very few are good at remembering the student.

That gap became the core idea behind Continuum, the project we built for a hackathon. We didn’t want another tutor that starts from zero every session and treats every conversation like it has never seen the learner before. We wanted something closer to a real teacher: a system that could remember past mistakes, notice patterns, adapt explanations, and eventually stop treating old misconceptions as active once the student had clearly improved.

In short, we wanted to build an AI tutor with a memory lifecycle.

The challenge, of course, was that we had to do it in hackathon conditions limited time, limited scope, and no room for building features that looked cool but didn’t actually strengthen the core idea. So instead of trying to build a massive platform, we focused on the smallest version of the product that could still prove one thing convincingly:

Continuum is not just an AI tutor. It is an AI tutor that remembers, recalls, improves, and forgets.

This post is a breakdown of how we structured that build across four days using Cognee as the memory layer, FastAPI for the backend, and an LLM-driven tutoring loop on top.
The core idea behind Continuum

Before getting into the build process, it helps to define the product in one sentence.

Continuum is a memory-driven AI tutor designed to learn how a specific student learns over time.

Instead of treating every tutoring session as a blank slate, the system is built around four memory operations:

Remember: store student interactions, answers, misconceptions, and strategy outcomes
Recall: retrieve relevant past context before teaching the next concept
Improve: periodically synthesize memory into better teaching preferences and mastery insights
Forget: remove outdated misconceptions once the student has clearly overcome them

That lifecycle became the backbone of the entire architecture. Everything else curriculum, tutoring, grading, dashboards was built around making those four operations meaningful and visible.
Why we planned the build day by day

Hackathons punish vague architecture.

If you try to build “an AI tutor with memory” as one giant fuzzy idea, you end up with half-working services, no clear demo story, and no time to debug the one thing that actually matters. So we broke Continuum into four days where each day unlocked the next:

Day 1: prove memory works and centralize the lifecycle logic
Day 2: build the curriculum layer and the first tutoring loop
Day 3: let the tutor learn from student answers and adapt its strategy
Day 4: make the system’s learning visible through a dashboard and timeline

That order mattered a lot. We didn’t want to build tutoring logic on top of an unverified memory system. We didn’t want to build a dashboard before there was meaningful memory data to show. And we definitely didn’t want to spend hours polishing UI if the tutor itself couldn’t demonstrate continuity.
Day 1 — Build the foundation before building the tutor

The first day was dedicated to one thing above all else: making sure Cognee actually worked before we built on top of it.

It sounds obvious, but it’s one of the easiest mistakes to make in a hackathon. You install a tool, assume the integration is fine, start writing business logic, and then discover two days later that your memory pipeline isn’t behaving the way you thought it was. We wanted to avoid that entirely.

So before writing any real tutoring features, the first task was to run a real local memory test. We created a fake student interaction, stored it through a “remember” call, and then issued a “recall” query against it to confirm that the returned context actually made sense. Not just “it didn’t crash,” but “the memory is being stored and retrieved in a way that would be useful to a tutor.”

That one-hour verification step was probably one of the highest-leverage decisions in the whole project. It meant the rest of the architecture could be built with confidence instead of guesswork.
Creating the Memory Lifecycle Service

Once Cognee was verified, the next move was to build what became the heart of Continuum: the Memory Lifecycle Service.

Rather than letting every part of the backend talk to Cognee directly, we created a single centralized Python module that owned all memory interactions. This module exposed a clean set of functions:

remember()
recall()
improve()
forget()

We also added a logging utility that recorded every lifecycle event with a timestamp and a trigger reason.

This ended up being one of the best architectural decisions in the project. It gave us:

A single place to debug memory behavior
If recall returned bad context or forget wasn’t firing correctly, we knew exactly where to inspect.
A single place to instrument for the demo
Since every memory operation passed through one module, it became easy to surface lifecycle events in the UI later.
A clean boundary for the rest of the backend
Other services didn’t need to know anything about Cognee internals. They just imported the lifecycle module.

Even in a hackathon setting, centralizing memory logic paid off immediately. It kept the architecture understandable and gave us a strong “Best Use of Cognee” story right from the start.
Setting up the FastAPI skeleton

With memory in place, we created the FastAPI project structure so the other services had a home. This wasn’t the day for building lots of endpoints; it was about creating the skeleton — folders, routers, and a simple health-check route — so the backend was ready to grow cleanly over the next three days.

By the end of Day 1, the flashy parts of Continuum still didn’t exist. But the most important part did: we had a working memory layer and a backend structure built around it.
Day 2 — Teach the tutor what to teach

With the memory infrastructure ready, Day 2 shifted from “can the system remember?” to “can the system actually tutor?”

To make that happen, we built two pieces: a Curriculum Service and the first version of the Tutoring Engine.
Keeping the curriculum intentionally small

For the hackathon, we made a deliberate scope decision: the curriculum would be small, fixed, and carefully chosen.

Instead of trying to support multiple subjects or ingest a giant knowledge base, we created a compact syllabus — roughly 10 to 15 concepts in a single domain, such as high-school algebra or basic Python programming. Each concept included its prerequisite relationships in natural language.

That dataset was ingested into Cognee as a shared curriculum graph. Unlike student memory, which evolves constantly, the curriculum itself stays stable. It doesn’t belong to one student; it belongs to the tutoring system as a whole.

Once ingested, we tested it by asking recall-style questions such as:

Which concepts depend on loops?
What should a student know before solving linear equations?
What comes after variables and expressions?

As soon as those queries worked, the curriculum side was effectively complete. We didn’t need it to be huge; we just needed it to be structurally meaningful enough to support tutoring decisions.
Building the first tutoring loop

The more important part of Day 2 was the Tutoring Engine Service, which acted as the orchestrator of the learning loop.

Its job was simple in concept but powerful in practice:

Accept a student ID and a current concept
Call recall on that student’s memory to surface weak areas, past struggles, or relevant misconceptions
Consult the curriculum graph to understand where the concept sits in the learning path
Use both of those inputs to decide what to focus on
Ask the LLM to generate a tutoring question

At this stage, the teaching strategy itself was still hardcoded. That was intentional. We didn’t need adaptive strategy selection yet; we just needed the tutor to generate a reasonable question using student memory and curriculum context.

The output of the tutoring engine was a payload containing:

the generated question
the concept being covered
the teaching style used

Most importantly, we wired it to a real API endpoint by the end of the day. That gave the frontend something concrete to call and turned the tutoring loop into a real, testable part of the system.

By the end of Day 2, Continuum could do something meaningful: it could look at a student’s past context, look at the concept graph, and generate a targeted tutoring prompt instead of a generic one.
Day 3 — Make the tutor learn from the student

By Day 3, Continuum could ask questions. What it still couldn’t do was learn from the answers.

That changed once we built the grading, misconception, and strategy-selection pipeline.
Grading answers and storing real learning signals

The first service we added was an endpoint that accepted a student answer and sent it to the LLM for evaluation.

The LLM’s job wasn’t just to mark the answer correct or incorrect. If the student was wrong, it also had to classify the type of misconception in plain language.

That distinction mattered a lot. “Wrong answer” is not useful memory by itself. But “confused variable assignment with comparison” or “used the right formula with the wrong sign convention” is the kind of information that actually helps a future tutoring session.

Once the grading result came back, the backend called the Memory Lifecycle Service’s remember function and stored the full interaction:

concept
student answer
correctness
misconception type, if any
teaching strategy used

At that point, memory was no longer storing abstract test data. It was storing real tutoring interactions.
Strategy selection: moving from static tutoring to adaptive tutoring

Once we had a few interactions in memory, we could build the Strategy Selection Service.

This service looked at a student and a concept type, queried memory for past strategy performance, and then selected the next teaching style based on what had actually worked.

For example, if a student consistently responded better to analogy-based explanations than direct conceptual prompts, the tutor could start favoring that style. If step-by-step decomposition worked better for one topic than another, that could influence the next question generation call.

This is where Continuum started to feel less like “LLM + memory” and more like a real adaptive tutoring system. The tutoring engine was updated so it no longer used a hardcoded teaching strategy; instead, it requested the current best-fit strategy from the strategy service before generating the next question.
Adding improve and forget triggers

The last major piece of Day 3 was implementing the improve and forget lifecycle triggers.
Improve

We configured improve to fire automatically after every five student interactions. The idea was that the system should periodically step back and synthesize what it had learned so far:

Which misconceptions keep recurring?
Which teaching strategies are working best?
Which concepts appear stable and which still look shaky?

We also exposed improve as a manual endpoint for demo purposes. That meant we could trigger it live during the pitch and visibly show the system “updating” its understanding of the student.
Forget

The forget trigger represented something equally important: recognizing when a student has genuinely moved past a misconception.

We defined a simple rule for the hackathon version: if a concept that previously had a misconception attached to it was answered correctly three times in a row, the system would mark that misconception as resolved and trigger a forget event.

This mattered because a good tutor shouldn’t just remember failures forever. It should also know when to stop treating an old weakness as current truth.

By the end of Day 3, Continuum had crossed a major threshold. It wasn’t just storing student history anymore — it was using that history to adapt teaching behavior and update its internal model of the learner.
Day 4 — Turn the memory system into something visible

A memory-driven system is only compelling if you can actually show the memory doing something.

That made Day 4 all about visibility, polish, and demo readiness.
Building the dashboard aggregation endpoint

The first feature we added was a Dashboard Aggregation endpoint. This endpoint called the memory layer to assemble a student-facing snapshot of learning state, including:

mastery levels per concept
currently active weak areas
preferred teaching strategies by concept
recent tutoring outcomes

The goal wasn’t just to return raw memory entries. It was to convert memory into something interpretable — a structured summary that the frontend could turn into a meaningful dashboard.
Building the session timeline

Next, we added a Session Timeline endpoint that returned a chronological list of lifecycle events, especially every time remember, improve, or forget was triggered.

This became one of the most important pieces of the demo.

Why? Because it made Continuum’s “self-improving tutor” claim visible. Instead of saying “trust us, memory is happening behind the scenes,” we could show a real timeline of events:

a misconception being remembered
a strategy pattern being improved
an outdated weakness being forgotten after repeated correct answers

That timeline turned the memory lifecycle from an invisible implementation detail into a product feature the judges could actually see.
Running full end-to-end sessions

The rest of Day 4 was spent doing something that often gets neglected in hackathons: running the full flow with real interaction data instead of mock payloads.

We simulated multiple student sessions, intentionally answered some questions incorrectly, corrected them later, triggered improvement cycles, and watched whether the dashboard and timeline changed in the way we expected.

This is where a lot of hidden issues tend to surface:

recall not returning enough useful context
misconception labels being inconsistent
strategy selection not changing when it should
frontend views failing to reflect lifecycle events correctly

By the time demo prep started, the goal was not “every feature exists.” It was “the core story works end to end.”

And the story was simple: the tutor remembers what happened, changes how it teaches, and updates its view of the student over time.
What made this approach work

Looking back, the four-day structure worked because it respected dependency order.

We didn’t try to make the tutor adaptive before memory was reliable.
We didn’t try to build dashboards before we had lifecycle data worth showing.
We didn’t try to support a giant curriculum when a small concept graph was enough to prove the idea.

Each day ended with a meaningful checkpoint:

Day 1: memory works and lifecycle operations are centralized
Day 2: the tutor can generate questions using memory + curriculum context
Day 3: student answers change future teaching behavior
Day 4: the learning process becomes visible and demo-ready

That progression kept the project grounded. Instead of trying to build everything at once, we kept asking a more useful question:

What is the smallest next layer that makes the core idea more real?
Lessons learned from building Continuum

Building Continuum in a hackathon taught us a few things that go beyond this specific project.

Verify your critical dependency on Day 1

If your entire product depends on memory, don’t “assume the memory layer is probably fine.” Test it immediately with a real workflow.

Centralize the part of the system you’ll need to explain

The Memory Lifecycle Service wasn’t just useful for code organization. It also made the product easier to reason about, easier to debug, and easier to explain to judges.

Small datasets are fine if they prove the concept well

We didn’t need a giant educational corpus to demonstrate adaptive tutoring. A compact curriculum graph was enough because the real focus was on the memory lifecycle, not on content scale.

A good demo needs visible system behavior

“AI with memory” is not compelling if memory stays hidden in logs. The dashboard and timeline mattered because they turned architecture into something a human could understand at a glance.

The best hackathon architecture is the one that supports the story

In the end, Continuum wasn’t trying to prove that we could build every tutoring feature imaginable. It was trying to prove one thing well:

an AI tutor becomes far more interesting when it can remember the student, adapt its teaching, and stop treating learning as a series of disconnected sessions.

That’s the story we optimized for, and that’s what shaped the build.
Closing thoughts

Continuum started as a simple frustration with the current generation of AI tutors: they are often smart, but they are rarely continuous.

They can explain a concept. They can generate a quiz. They can answer follow-up questions. But most of them still forget who the student is the moment the session ends.

We wanted to explore what happens when that changes.

What happens when a tutor remembers the patterns behind a student’s mistakes?
What happens when it adjusts its teaching strategy based on what has worked before?
What happens when it knows not only what the student got wrong, but also when they’ve finally moved past that weakness?

That’s the direction Continuum is built around.

And while the hackathon version is only the first step, it already made one thing clear to us:

the future of AI tutoring isn’t just better answers — it’s better memory.

Day 1: The Day I Stopped Treating Memory as an Afterthought

Mayank Roy — Fri, 03 Jul 2026 09:41:26 +0000

I almost made the same mistake every developer makes when building an AI app.

I was ready to open my laptop, spin up a FastAPI server, connect an LLM, start streaming responses, and then somewhere near the end, probably at 2am bolt on some kind of memory system as an afterthought. A dictionary here. A database table there. Maybe a list of the last five messages shoved into the context window and called "memory." I have done this before. It always feels fine until it very obviously isn't.

This time I caught myself.

How We Got Here

We are building a project called Continuum for the WeMakeDevs Hangover Part AI hackathon. The premise of the hackathon is almost offensively simple: your AI woke up in Vegas with no memory of last night. Build one that doesn't forget. The tool they want you to use is called Cognee, a hybrid graph-vector memory layer for AI agents, and the judging is literally weighted on how deeply you use it.

So I sat down on Day 1 with one rule: don't touch the tutor logic, don't touch the LLM prompts, don't touch the frontend. Just get Cognee working and build the layer everything else will sit on top of.

It sounds boring. It was the best decision I made all week.

What Even Is Cognee

I'll be honest, my first reaction to Cognee was skepticism. Another memory library? Isn't that just a vector store with extra steps?

No. And the difference matters more than I expected.

A vector store gives you semantic search. You embed some text, you store the embedding, you query against it later and get back chunks that are semantically similar to your query. That's useful, but it's flat. Every piece of information has the same relationship to every other piece: none.

Cognee builds a knowledge graph on top of that. When you call remember() with a piece of text, it doesn't just embed it. It runs an extraction pass that pulls out entities and relationships, and stores those as nodes and edges in a graph. So when you later call recall(), it isn't just doing vector similarity search, it's doing graph traversal too. It can follow chains of relationships. It can answer multi-hop questions. It can connect information across different things you told it at different times.

For a tutoring app, this is the difference between "the student got question 4 wrong" (a flat fact) and "the student has a sign error misconception on factoring, which is a prerequisite of completing the square, which is what they're stuck on now" (a chain of relationships). The second one is what actually helps you teach better.

Cognee exposes four operations, and the hackathon is explicitly built around them:

remember() ingests text, files, or URLs and structures them into the knowledge graph. recall() queries that graph with a natural language question and returns relevant results using both semantic similarity and graph traversal. improve() runs a post-ingestion enrichment pass that re-weights nodes and prunes stale or redundant data. forget() surgically removes data from the graph without wiping everything else.

Four operations. Total recall. That's their tagline and honestly it's accurate.

The First Thing I Did Was Prove It Actually Works

Before writing a single line of application code, I wrote a throwaway test file. Not a unit test. Not a pytest fixture. Just a plain Python script called test_cognee.py that did three things:

Called remember() with one sentence describing a fake student interaction. Called recall() with a question about that interaction. Printed the result.

Then I ran it.

This took about forty minutes including the time I spent reading the Cognee docs to get the config right, specifically figuring out that it needs an LLM API key to do its graph extraction during remember() . That was the one thing that tripped me up I expected it to work like a pure vector store where you just need an embedding model, but the graph extraction step calls an LLM internally. Once I had that configured in my .env file, it worked.

And when recall() returned a response that actually related to what I had just stored, something clicked. This wasn't a toy. The graph traversal was surfacing the right information from a single fact I had stored ten seconds ago. I could already see how this would behave across hundreds of stored interactions.

I deleted the test file. I was unblocked.

The reason I'm emphasising this step is that it's very tempting to skip it. You want to build things. Sitting and running a five-line test script feels like procrastination. But discovering that your entire memory layer doesn't work on day three, when everything else is already built on top of it, is genuinely catastrophic for a five-day hackathon. One hour of proof-of-life on day one is worth eight hours of debugging on day three.

Why FastAPI

I'm a backend developer. I've used Flask, Django, and FastAPI. For this project FastAPI was the obvious choice and I want to explain why beyond just "it's fast."

The killer feature for this specific project is async support. Cognee's operations : remember(), recall(), improve(), forget() are all async functions. They do IO: they call LLMs, they write to databases, they traverse graphs. If you build a synchronous server on top of async operations you either block everything or you start wrestling with event loops in ways that will make you cry at 11pm on day four.

FastAPI is async-native. Every endpoint is an async function. You await your Cognee calls directly inside your route handlers with no ceremony. The mental model is clean and it stays clean.

Beyond that: automatic OpenAPI docs that your frontend teammate can use to understand the API without you explaining every endpoint, type validation via Pydantic, and a startup lifespan hook where you can validate your environment config before the server starts accepting requests. That last one matters because catching a missing API key at startup with a clear error is infinitely better than catching it mid-request with a cryptic 500 during your demo.

The Memory Lifecycle Service: The Most Important Thing I Built All Day

After proving Cognee works, I built one file that became the backbone of the entire backend: memory.py .

The concept is simple. Instead of calling cognee.remember() directly from five different places in the codebase, every Cognee operation goes through this single module. Every other service imports from here and only from here.

Why? Three reasons.

Debugging. When something breaks with memory and something will break there is exactly one place to look. Not scattered across the tutoring engine, the grading service, the strategy selector, and two routers. One file.

The demo. Every call to remember(), recall(), improve(), and forget() gets logged to a JSON file with a timestamp, the student ID, the dataset, and a plain-English description of what triggered it. During the demo you can show judges a literal timestamped receipt of every memory operation the system performed. That's not just a nice UI detail, that's your answer to the "best use of Cognee" judging criterion made tangible.

Discipline. Building this first sets a team norm. Nobody reaches around the service and calls Cognee directly, because the central module exists and is obviously the right place. It prevents the kind of architectural drift that happens in hackathons where everyone is moving fast and shortcuts accumulate.

The module has five functions that map directly onto the four Cognee operations, plus a sixth utility that reads back the log. remember_interaction() takes a structured description of a student's attempt and stores it. recall_student_context() takes a student ID and a query string and returns relevant history. improve_student_memory() triggers the enrichment pass on a student's dataset. forget_resolved_misconception() prunes resolved misconceptions and re-runs improve to keep the graph clean. And get_lifecycle_log() returns the event history, filterable by student ID.

Writing these five functions took maybe two hours. Using them for the rest of the week saved us from an entire category of problems.

What the End of Day 1 Looked Like

By the time I pushed to the repo at the end of the day, here's what existed:

A virtual environment with four dependencies. A .env.example file so teammates don't have to ask how to configure things. A config.py that centralises every environment variable and validates them at startup. The memory.py service with all four operations and logging. A tests/test_memory_service.py that runs the full lifecycle — remember, recall, improve, forget — and verifies the log contains all four events. A FastAPI app in main.py with a working health check endpoint. And a _README _ section explaining exactly how to get the server running.

Nothing about the actual tutoring logic existed yet. No question generation. No grading. No strategy selection. And that was correct.

The foundation was solid. Everything built on top of it over the next four days had a place to stand.

The Thing I Keep Coming Back To

There's a version of this project where I spent Day 1 writing prompt templates, arguing about whether to use GPT-4o or Claude, and building a chat endpoint that kind of works but has no real memory. I've seen that project. It's the one that, during the demo, has to answer "how does it remember the user?" with "well, we pass the last few messages as context."

The answer I have instead is: it builds a per-student knowledge graph. It stores every interaction as a structured memory. It recalls relevant history using graph traversal, not just keyword matching. It improves its graph after every session. It forgets resolved misconceptions instead of letting stale wrong data pollute future teaching.

That answer exists because of what we built on Day 1.

Memory isn't a feature you add at the end. For an AI agent, memory is the architecture. Get that right first and everything else is just building rooms in a house that already has a solid foundation.

This is Day 1 of our build log for Continuum, built during the WeMakeDevs Hangover Part AI hackathon (June 29 – July 5, 2026).

🛠️ LinkedIn Post: Major Updates in DevConnect

Mayank Roy — Fri, 18 Jul 2025 14:01:49 +0000

🔍 What’s New?

1️⃣ Enhanced Repo Cards

• 🚀 Refined layout in both Dashboard and MainFeed for a clean, polished look
• 📋 Added Copy Clone Link buttons for one-click access

2️⃣ Richer Media Layout

• 🎨 Refined image/video grid styling—crisp, responsive, and visually appealing

3️⃣ 🔐 Stronger Sign-up Protection

• 🔄 Password normalized before hashing
• ✅ Enforced full validation: length, character types & edge cases

💡 Why It Matters

Better UX = happier users
Enhanced security = peace of mind
Faster workflows = dev momentum

📌 What’s Next

Lightbox/modal previews
Inline error alerts
Accessibility improvements

Thrilled to see how these changes improve DevConnect—stay tuned for more upgrades! 🌟

I’m excited to share some 🔥 updates in DevConnect

Mayank Roy — Thu, 17 Jul 2025 13:13:04 +0000

✨ feat: Added CommentBox & CommentList components to enable seamless user comments!

✅ feat: Refactored MainFeed and LikeButton to include commenting and improve repo display.

🔧 feat: Cleaned up media upload logic, integrated comments and likes—everything now works together beautifully in the feed.

Why it matters:

Users can now comment directly on posts and see updates instantly—better engagement!
Cleaned component structure and Redux logic help maintainability and scalability.
UI is more intuitive and interactive, blending likes, comments, and media seamlessly.

💬 I’d love your feedback: How do you approach comments in social features? Any libraries or patterns you swear by?

🚀I’m excited to share the latest improvements in DevConnect!

Mayank Roy — Wed, 16 Jul 2025 10:26:32 +0000

✨ What’s new:

Improved repo display in MainFeed — simplified logic, removed useFetchRepos hook, and built cleaner component structure.
CommentBox feature — users can now add comments directly on posts. The functionality is powered by a new createAsyncThunk in the Redux slice and handled cleanly via extraReducers.
UI clarity boost — enhanced layouts with refined styling, making media, likes, and comments easy to read and interact with.

🛠️ The why behind the changes:

Removed unnecessary abstraction (useFetchRepos) to reduce complexity and improve render performance.
Leveraged Redux Toolkit’s createAsyncThunk for robust async handling—just like industry standards .
Ensured a seamless user experience: comment submissions instantly update the feed via optimized state handling.

🔍 What this means for users:

Quick, responsive commenting experience.
Streamlined UI with intuitive layout and feedback.
Clearer codebase = faster iteration for future enhancements.

🙌 Next steps:

Add delete & edit options for comments
Style feedback/loading states
Optimize media previews

Curious to hear your input—what’s your approach to handling real-time comments in web apps?

🚀 What’s New in DevConnect

Mayank Roy — Mon, 14 Jul 2025 12:05:00 +0000

📥 Media upload revamped – improved file handling and refreshed UI for smoother post creation via the Dashboard.

🔁 Refactored backend logic – streamlined both create & update flows, now using githubRepoName for clarity.

🧩 New hook added – useFetchRepos neatly fetches GitHub repository data, keeping concerns separated and components clean.

💡 Why It Matters

⚡️ Upload fast, post faster – better performance and UX when adding images/videos.

🧹 Cleaner code = fewer bugs, easier maintenance, and less confusion around repo fields.

✨ Modular patterns with hooks make fetching GitHub repos reusable and efficient.

👀 What’s Next?

Adding cross-check badges (stars/forks) next to GitHub links.
Implementing error/loading feedback in the UI.
Building out comments & notifications features.

💬 I'd Love Your Feedback

How do you handle media file uploads and GitHub data in your web apps? Any best practices or libraries you'd recommend?

🚀 DevConnect Progress

Mayank Roy — Fri, 11 Jul 2025 14:15:05 +0000

✅ Added Like toggling — users can now like/unlike posts, stored in Redux

🔄 Refactored how Dashboard fetches posts

💡 Introduced new LikeButton component for consistent UI across app

🤯 My biggest headache?

Turns out the root cause was a damn route spelling mistake (/post instead of /posts) — yeah, wasted HOURS on that one. 😫 And if that wasn’t enough, the like state wasn’t updating instantly in the UI due to a mix‑up between React component state and Redux state. Figuring that out taught me so much about state flow and debugging in React + Redux .

✅ Why it matters

Centralized state with Redux ensures like counts are always accurate and consistent.
A reusable LikeButton simplifies future maintenance and styling.
Cleaner fetch logic = fewer bugs and better performance.

🎯 What’s next?

Improve real-time UI updates (optimistic rendering when liking/unliking)
Add feedback/loading indicators around like actions
Build out comments feature next 🚧

💬 I'd love your insights:

Ever spent hours debugging a typo route issue? How did you stop that cycle?
How do you handle global vs component state for UI vs data?
Your tips or stories would be amazing to hear!

🚀 New endpoint: Fetch user profile data reliably on demand

Mayank Roy — Thu, 10 Jul 2025 04:26:47 +0000

🛡️ Global error handler: Centralized Express middleware to catch and format API errors consistently

📦 Clean imports: Refactored Axios imports to streamline HTTP calls across components

🐛 My debugging nightmare

I spent hours chasing down an elusive error—requests were sporadically failing, but the message didn’t point to any file or component. Tracking it felt like chasing ghosts through async routes. Debugging this taught me the difference between scattered try/catch and a centralized error .
That moment was brutal…but so rewarding when I finally found and fixed the root cause. Seriously, nothing sharpens your skills quite like those moments.

✅ Why this matters

🧩 Cleaner code – one place for all error handling makes services easier to maintain

📈 Better UX – users see consistent error messages, not ugly stack traces

⚡ Developer sanity – less time lost debugging and more time building

💭 What’s next?

Improving frontend UX around loading/error states
More API endpoints: updating profiles, fetching followers, etc.
Deepening test coverage for error paths

🎙️ I’d love your input
Any tips for debugging Express errors faster?
How do you handle Axios imports and error handling in large React apps?
Always grateful for insights from the community 🙏

🚀 DevConnect Progress Update!

Mayank Roy — Wed, 09 Jul 2025 07:12:46 +0000

Just pushed two major improvements:

🔀 Enhanced routing & UI components — improved how posts are created, edited, and displayed.

🗂️ Dashboard tabs added — now users can easily switch between Posts, Media, and GitHub repos.

Fun fact:

while building the profile post feed, I accidentally overwrote the Main feed—so everything showed up in the wrong place! 😅 Good catch during testing, and now it’s fixed.

Also, I admit: I didn’t document these changes from the start, but I’m committing to better documentation going forward 📚✅.

✅ Why it matters:

Cleaner navigation and UI make DevConnect more intuitive.
Tabs give focused access to different content types.
And hey—errors like these remind me testing matters more than perfection.

💭 Over to you:

Have feedback on the new tab setup?
What's your go-to pattern for documenting UI changes?
Let me know—I’m all ears!

🚧 Pre-Launch DevConnect Update:

Mayank Roy — Tue, 08 Jul 2025 08:36:51 +0000

Still no live demo yet… but hit a major milestone today: DevConnect can now fetch GitHub repos and support image/video uploads—despite a hell of a learning curve!

🧑‍💻 What’s Working (So Far):

✅ GitHub Integration: DevConnect now fetches public repos from GitHub—it feels amazing to see real code showing up in the profile!

✅ Media Uploads: Image and video uploads work (thanks, Cloudinary), even though I accidentally uploaded test videos 30 times before fixing my file-path logic.

⚠️ Challenges Along the Way:

🐞 That ONE async bug: a missing await caused duplicate uploads—my Cloudinary account saw a surge in nonsense. Debugging that definitely earned me ☕.

🧩 State management chaos: toggling between Context & Redux Toolkit had me rethinking my approach—but it's in a solid place now.

🧭 UI polish: making responsive post cards look nice on mobile took way more effort than I expected.

🎯 Why Keep Building
I'm working on DevConnect pre-launch to:

Blend social + code sharing—so devs don’t have to juggle GitHub and Twitter separately.
Create an early beta community, whose feedback will help shape features like comments on repos and like buttons.

Note: While there’s no live button yet, every bug fix and user test brings it closer. I’m also researching how to tease development publicly—informed by advice to build excitement early on 🧠.

💡 Can You Help?

What feature matters most to you? Issues tracker? Project boards? Commenting on repos?
Want to swing by the early demo? DM me—I’d appreciate any feedback.

DevConnect is still in progress: no live demo yet.
But it's already pulling real GitHub repos + uploading media.
Lots of cleanup & polish still ahead—just sharing wins and lessons early 👊.

Day 8: Exploring Functions in C++ - The Building Blocks of Reusability

Mayank Roy — Sun, 19 Jan 2025 08:41:49 +0000

1. Functions in C++ (Syntax, Return Type, etc.)

A function is a block of code designed to perform a specific task.
Functions in C++ follow this basic syntax:

  returnType functionName(parameters) {
    // function body
}

Return Type: Specifies the data type of the value returned by the function. Use void if no value is returned.
Function Name: Describes what the function does.
Parameters: Input values for the function (optional).

#include <iostream>
using namespace std;

// Function to check tea temperature
int checkTeaTemperature(int temperature) {
    return temperature;
}

int main() {
    int temp = checkTeaTemperature(85);  // Function call
    cout << "The tea temperature is " << temp << "°C" << endl;
    return 0;
}

2. Declaring a Function

Function declaration tells the compiler about the function’s name, return type, and parameters. It’s also called a function prototype.
The function body is defined elsewhere.

#include <iostream>
using namespace std;

// Declaring the function (prototype)
void serveChai(int cups);

int main() {
    serveChai(3);  // Function call
    return 0;
}

// Function definition is done later
void serveChai(int cups) {
    cout << "Serving " << cups << " cups of chai!" << endl;
}

3. Defining a Function

A function definition includes the full function with the body.
You must define the function after declaring it if it’s not inline.

#include <iostream>
using namespace std;

// Function definition with body
void makeChai() {
    cout << "Boiling water, adding tea leaves, and serving chai!" << endl;
}

int main() {
    makeChai();  // Calling the function
    return 0;
}

4. Calling a Function

To execute a function, you call it by its name followed by parentheses.
If the function takes arguments, pass them inside the parentheses.

#include <iostream>
using namespace std;

// Function to brew tea
void brewChai() {
    cout << "Chai is being brewed!" << endl;
}

int main() {
    brewChai();  // Function call
    return 0;
}

5. Function Parameters (Formal, Actual, Default Parameters)

Formal parameters: Defined in the function signature.
Actual parameters: Values passed during the function call.
Default parameters: Parameters with default values if none are passed.

#include <iostream>
using namespace std;

// Function with default parameter
void serveChai(string teaType = "Masala Chai") {
    cout << "Serving " << teaType << endl;
}

int main() {
    serveChai();               // Uses default parameter
    serveChai("Green Chai");    // Uses actual parameter
    return 0;
}

6. Pass by Value

Pass by value means the function receives a copy of the argument. Changes made inside the function do not affect the original variable.

#include <iostream>
using namespace std;

void pourChai(int cups) {
    cups = cups + 1;  // Modifies local copy
    cout << "Poured " << cups << " cups of chai!" << endl;
}

int main() {
    int chaiCups = 2;
    pourChai(chaiCups);  // Passing by value
    cout << "Total chai cups outside function: " << chaiCups << endl;
    return 0;
}

7. Pass by Reference

Pass by reference passes the actual variable, so changes in the function affect the original variable.

#include <iostream>
using namespace std;

void refillChai(int &cups) {  // Pass by reference
    cups += 2;
    cout << "Refilled to " << cups << " cups of chai!" << endl;
}

int main() {
    int chaiCups = 3;
    refillChai(chaiCups);  // Passing by reference
    cout << "Total chai cups now: " << chaiCups << endl;
    return 0;
}

8. Scope of Variables

Variables declared inside a function have local scope (accessible only within the function).
Variables declared outside all functions have global scope (accessible from any function).

#include <iostream>
using namespace std;

int globalChaiStock = 100;  // Global variable

void serveChai() {
    int localCups = 5;  // Local variable
    cout << "Serving " << localCups << " cups from " << globalChaiStock << " total stock." << endl;
}

int main() {
    serveChai();
    cout << "Global chai stock after serving: " << globalChaiStock << endl;
    return 0;
}

9. Function Overloading

Function overloading allows multiple functions with the same name but different parameter types or numbers.

#include <iostream>
using namespace std;

// Function overloading
void brewChai(int cups) {
    cout << "Brewing " << cups << " cups of chai." << endl;
}

void brewChai(string teaType) {
    cout << "Brewing " << teaType << "." << endl;
}

int main() {
    brewChai(3);             // Calls int version
    brewChai("Masala Chai");  // Calls string version
    return 0;
}

10. Lambda Functions

A lambda function is an anonymous function that can be defined inline using the[] syntax.
They’re useful for short, simple functions.

#include <iostream>

using namespace std;



int main(){

   //lambda
   [](int cups){
        cout << "Preparing " << cups << " cups of tea" << endl;
   }(5);

    return 0;

}

Summary:

Function Declaration & Definition: Tell the compiler about a function and define what it does.
Calling Functions: Execute the function by passing arguments if required.
Pass by Value/Reference: Controls whether changes affect the original value or a copy.
Function Overloading: Allows multiple functions with the same name but different parameter lists.
Lambda Functions: Short, inline functions used for simple tasks.