Forem: Dulaj Thiwanka

What 24 Hours of Non-Stop Coding Taught Me About Being a Developer

Dulaj Thiwanka — Sat, 04 Apr 2026 17:05:58 +0000

I Tried Building a Full App in 24 Hours… and It Was Way Harder Than I Expected

I’ve started more projects than I can count.

Some had amazing ideas.
Some had clean designs.
Some even had “this could actually work” potential.

But most of them had one thing in common:

They were never finished.

And if you’re a developer, you probably know this feeling a little too well.

You start strong.
You feel motivated.
You imagine the final product.

Then slowly…

You get stuck.
You overthink.
You tweak things that don’t matter.
And eventually, the project just… dies.

No deadline. No pressure. No urgency.

Just another unfinished folder sitting on your laptop.

So one day, I decided to break that pattern.

Not by learning more.
Not by watching another tutorial.

But by forcing myself into a corner.

The Challenge

I gave myself exactly 24 hours.

Not “over the weekend.”
Not “whenever I have time.”

24 real, continuous hours.

And the goal was simple:

Build a complete full-stack app. Start to finish.

That means:

Backend working
Frontend working
Database connected
Everything integrated

No fake demos. No half-built features.

Just something real.

The Stack (No Time to Experiment)

I didn’t want to waste time choosing tools, so I stuck to what I already knew:

React + Tailwind for the frontend
Node.js + Express for the backend
MySQL with Sequelize

This wasn’t about learning new tech.

This was about execution under pressure.

Hour 1–2: The Most Dangerous Phase

This part almost ruined everything.

I wasn’t coding yet.

I was thinking.

And thinking.

“Maybe I should build something unique…”
“What if I add authentication?”
“Should I make it scalable?”

It sounds productive.

But it’s actually a trap.

Because the more you think, the bigger the project becomes.

And the bigger the project becomes…

The less likely you are to finish.

Eventually, I forced myself to stop.

No more ideas. No more upgrades.

I picked something simple:

A basic task manager

Create. Update. Delete.

That’s it.

No login system. No complex features.

And honestly?

That single decision was the reason I didn’t fail.

Hour 3–8: Backend Flow State

This was probably the smoothest part of the entire challenge.

I set up:

Express server
API routes
Sequelize models
Database connection

Basic endpoints:

POST /tasks
GET /tasks
PUT /tasks/:id
DELETE /tasks/:id

Everything felt… under control.

No major bugs. No confusion.

I was in that “flow state” where things just click.

And for a moment, I genuinely thought:

“I might actually finish this early.”

Looking back, that was very optimistic

Hour 9–16: Where Everything Started Slipping

Frontend always looks easier than it actually is.

You think:

“It’s just UI.”

Until you start building it.

At first, it was fine.

I created components.
Styled with Tailwind.
Connected the API.

Then things started breaking.

Slowly.

Then all at once.

I ran into issues like:

State not updating correctly
API calls returning unexpected data
UI showing stale information
Components re-rendering in weird ways

At one point:

The database updated correctly… but the UI didn’t reflect it
Then I fixed the UI… and broke the API connection

It felt like a loop.

Fix one thing → break another.

This is the part most tutorials don’t show.

Because this is where real development happens.

Hour 17–22: The Mental Wall

This was the hardest phase.

Not because of complexity.

But because of fatigue.

After ~15 hours, your brain just slows down.

Simple bugs take longer to understand.
You reread the same code multiple times.
You start making small mistakes.

And then…

💥 CORS issues
💥 Endpoint mismatches
💥 Random errors that didn’t exist before

At one point I just stared at the screen thinking:

“Why is this even happening?”

This is where most projects die.

Not because they’re impossible.

But because the developer gives up.

Hour 23: A Shift in Mindset

Something changed here.

I stopped trying to make things “good.”

And started trying to make things work.

I asked myself:

“What is the minimum required for this app to function?”

And then I cut everything else.

No extra features
No refactoring
No polishing

Just core functionality.

This was the turning point.

Hour 24: Done… Not Perfect, But Done

And finally…

It worked.

Was it clean?
Not really.

Was it scalable?
Definitely not.

Was it something I’d proudly show in a portfolio?

Probably no.

But it was finished.

And that felt different.

Because finishing something under pressure hits in a way that slow projects don’t.

The Final App

Simple and honest:

Add tasks
Edit tasks
Delete tasks

That’s it.

No authentication.
No animations.
No “cool features.”

Just a working product.

What This Actually Taught Me

This wasn’t just a coding challenge.

It exposed how I work.

1. I Overthink Way More Than I Realize

Most of my delays weren’t technical.

They were mental.

2. Simplicity Is Not “Basic” — It’s Strategic

The smaller the scope, the higher the success rate.

3. Perfection Is Just a Delay Mechanism

Trying to make things perfect almost made me fail completely.

4. Execution Is a Skill

And like any skill, it improves under pressure.

5. Finishing Is Rare

Starting is easy.

Planning is easy.

Learning is easy.

But finishing?

That’s what separates people.

Would I Do It Again? 🤔

Yes.

But smarter.

Next time I would:

Define scope faster
Cut features earlier
Focus only on what matters

Because this challenge isn’t about building something impressive.

It’s about proving one thing:

You can finish what you start.

If You’re Still Reading…

Try this.

Seriously.

Give yourself 24 hours.

No extensions. No excuses.

Build something.

And when you’re done, ask yourself:

“Did I actually finish… or did I overthink again?”

The Ultimate Guide to Browser Storage: LocalStorage, IndexedDB, Cookies, and More

Dulaj Thiwanka — Thu, 12 Mar 2026 08:02:04 +0000

Modern browsers have evolved far beyond simple document viewers. Today they function almost like miniature operating systems running inside your computer. They manage memory, execute applications, cache resources, and even host databases.

One of the most powerful capabilities browsers provide is client-side storage the ability to store data directly on the user’s device.

Client-side storage allows web applications to:

Reduce server requests
Improve performance
Persist user preferences
Enable offline experiences
Cache network resources
Store complex application data

Without browser storage, modern web applications like Gmail, Notion, Spotify Web, and Figma would be significantly slower and far less capable.

In this article, we’ll explore the most important browser storage mechanisms available today:

Local Storage
Session Storage
Extension Storage
IndexedDB
Cookies
Cache Storage
Storage Buckets

Understanding these systems helps developers choose the right tool for each type of data.

Why Browser Storage Exists

Before diving into each storage system, it’s helpful to understand why browsers need storage mechanisms in the first place.

Early web applications relied entirely on servers. Every user action required a network request, and every piece of state lived on the server.

This approach had several problems:

High latency
Server overload
No offline capability
Poor user experience

Client-side storage solves these issues by allowing applications to store data locally.

For example:

A theme preference can be stored locally instead of requested every time.
Cached assets can load instantly without network requests.
Entire applications can function offline.

Modern browsers therefore provide multiple storage systems designed for different types of data.

1. Local Storage

Local Storage is the most widely known browser storage API. It provides a simple way to store persistent key–value data inside the browser.

The stored data remains available even after:

Page reloads
Browser restarts
System restarts

This makes Local Storage ideal for storing small pieces of persistent application state.

Characteristics

Key–value storage
Stores strings only
Persistent across sessions
Around 5–10 MB per origin
Synchronous API

The synchronous nature means Local Storage operations block the main thread, which is why it should only be used for small data.

Basic Usage

// Save data
localStorage.setItem("username", "dulaj");

// Retrieve data
const username = localStorage.getItem("username");

// Remove item
localStorage.removeItem("username");

// Clear all data
localStorage.clear();

Since Local Storage only stores strings, objects must be serialized using JSON.

const user = { name: "Dulaj", age: 23 };

localStorage.setItem("user", JSON.stringify(user));

const storedUser = JSON.parse(localStorage.getItem("user"));

Storage Scope

Local Storage is scoped by origin, which means:

protocol + domain + port

For example:

https://example.com

A different subdomain or port creates a different storage space.

Common Use Cases

Local Storage is commonly used for:

UI preferences
Theme settings
Language configuration
Feature flags
Remembering user interface states

However, Local Storage is not suitable for large datasets or high-frequency operations.

2. Session Storage

Session Storage is extremely similar to Local Storage but with a shorter lifespan.

Instead of persisting across browser restarts, Session Storage exists only during the lifetime of a browser tab.

Once the tab closes, the stored data is permanently deleted.

Characteristics

Key–value storage
Stores strings
Scoped per tab session
Around 5 MB capacity
Synchronous API

Each tab has its own isolated session storage, meaning two tabs from the same website do not share session data.

Example

sessionStorage.setItem("step", "2");

const step = sessionStorage.getItem("step");

Use Cases

Session Storage is useful when the stored data should not persist permanently.

Examples include:

Multi-step form progress
Temporary UI states
Checkout process data
Navigation history state

If the user refreshes the page, the data remains. If the tab closes, the data disappears.

3. Extension Storage

Browser extensions operate in a different environment than normal web pages. Because of this, browsers provide a dedicated Extension Storage API.

This API allows extensions to store configuration data, cached content, and synced settings.

Types of Extension Storage

Most browsers support three storage types:

storage.local

Stores data locally on the user's device.

storage.sync

Synchronizes data across devices using the browser account.

For example:

Chrome sync
Firefox sync

storage.session

Temporary storage for the extension session.

Example

chrome.storage.local.set({ theme: "dark" });

chrome.storage.local.get("theme", (result) => {
  console.log(result.theme);
});

Unlike Local Storage, Extension Storage APIs are asynchronous, making them more suitable for larger data operations.

Common Use Cases

Extensions use storage for:

User settings
Feature toggles
Cached extension data
Syncing configuration across devices

4. IndexedDB

When developers need to store large amounts of structured data, IndexedDB becomes the primary solution.

IndexedDB is a transactional NoSQL database built directly into the browser.

It allows developers to store complex data such as:

Objects
Files
Blobs
Structured datasets

Key Concepts

IndexedDB introduces several database concepts:

Database

The top-level container for stored data.

Object Store

Similar to tables in relational databases.

Index

Allows fast lookup of records.

Transaction

Ensures safe and consistent database operations.

Example

const request = indexedDB.open("AppDatabase", 1);

request.onupgradeneeded = (event) => {
  const db = event.target.result;

  const store = db.createObjectStore("users", {
    keyPath: "id"
  });

  store.createIndex("email", "email", { unique: true });
};

Once created, the database can store large volumes of structured data.

Advantages

IndexedDB provides several benefits:

Asynchronous API
Large storage capacity
Efficient querying through indexes
Offline functionality
Structured data storage

Real-World Usage

Many major applications rely on IndexedDB:

Gmail (offline email storage)
Google Docs
Notion
Figma
Progressive Web Apps

IndexedDB allows web apps to behave much more like native applications.

5. Cookies

Cookies are the oldest form of browser storage, originally designed to maintain state across HTTP requests.

HTTP itself is stateless, meaning each request is independent. Cookies solve this by storing small pieces of data that the browser automatically sends with each request.

Characteristics

Maximum size: ~4 KB
Automatically included in HTTP requests
Can have expiration times
Supports security flags

Example

document.cookie = "theme=dark; path=/; expires=Fri, 31 Dec 2026 12:00:00 UTC";

Security Flags

Cookies can be configured with additional security options.

HttpOnly

Prevents JavaScript access.

Secure

Only sent over HTTPS.

SameSite

Controls cross-site request behavior.

Example:

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict

Use Cases

Cookies are commonly used for:

Authentication sessions
Tracking identifiers
Personalization
Server-side preferences

Because cookies are included with every request, they should contain minimal data.

6. Cache Storage

Cache Storage is part of the Service Worker API and is designed for storing network resources.

Instead of storing arbitrary data, it stores HTTP request–response pairs.

This enables developers to implement custom caching strategies.

Example

const cache = await caches.open("app-cache");

await cache.add("/index.html");
await cache.add("/styles.css");
await cache.add("/app.js");

When a user visits the site again, the cached version can be served instantly.

Benefits

Cache Storage enables:

Offline web applications
Faster loading times
Reduced server load
Advanced caching strategies

Common Strategies

Cache First

Use cache before network.

Network First

Try network first, fallback to cache.

Stale While Revalidate

Serve cached version while fetching an updated version in the background.

These strategies are widely used in Progressive Web Apps (PWAs).

7. Storage Buckets

Storage Buckets are a relatively new browser storage concept aimed at improving storage management.

Instead of storing all application data in one shared space, developers can create separate logical buckets.

Each bucket can have its own:

Lifetime
Storage quota
Eviction priority

Example structure:

App Storage
├── user-data
├── cache
└── temporary-files

If the browser needs to free space, it can remove lower priority buckets first.

This prevents critical application data from being deleted unexpectedly.

Storage Buckets are still evolving but represent a major improvement in browser storage architecture.

Comparison of Browser Storage Options

Storage Type	Persistence	Capacity	Data Type
Local Storage	Persistent	~5–10 MB	Strings
Session Storage	Tab lifetime	~5 MB	Strings
Cookies	Configurable	~4 KB	Strings
IndexedDB	Persistent	Large	Structured objects
Cache Storage	Persistent	Large	HTTP responses
Extension Storage	Persistent	Large	JSON-like
Storage Buckets	Managed	Large	Multiple types

How Modern Web Apps Use Browser Storage

Most production web applications combine multiple storage systems.

For example:

A Progressive Web App might use:

Local Storage for UI preferences
IndexedDB for large application data
Cache Storage for offline assets
Cookies for authentication sessions

This layered storage architecture enables fast, responsive, and reliable web applications.

Final Thoughts

Browser storage has evolved dramatically over the past decade. What once started as simple cookies has grown into a complete ecosystem of storage technologies.

Today, browsers provide:

Key–value storage
Databases
Network caches
Offline storage systems
Structured storage management

This capability allows web applications to behave increasingly like native desktop or mobile apps.

Understanding how each storage system works — and when to use it — is a critical skill for modern web developers building scalable and high-performance applications.

Git, Explained

Dulaj Thiwanka — Tue, 03 Feb 2026 11:05:22 +0000

Git is everywhere.
Jobs expect it. Teams depend on it. Tutorials assume you already understand it.

And yet, many developers use Git daily while secretly hoping nothing goes wrong.

This article is not about memorizing commands.
It’s about understanding what Git is thinking, so the commands stop feeling dangerous.

We’ll go slowly. Very slowly. On purpose.

Part 1: Why Git Exists (A Very Human Problem)

Imagine writing a document over several weeks.

You save versions like:

report.docx
report_final.docx
report_final_v3_REAL.docx

Now imagine three people editing that document at the same time.

That chaos is what Git was built to prevent.

Git exists to:

Track changes over time
Let multiple people work safely
Make mistakes reversible
Preserve context (the why, not just the what)

Git is not just backup.
Git is structured memory.

Part 2: The Mental Model That Changes Everything

Here’s the idea that makes Git stop feeling random:

Git does not track changes.
Git tracks snapshots.

Every commit is a photograph of your entire project folder at a specific moment in time.

If a file hasn’t changed, Git doesn’t store it again.
It simply points to the previous version.

This is why:

Git is efficient
Git is fast
Git history feels immutable

Once something is committed, it becomes a historical fact.

Part 3: Creating a Repository (Where Memory Begins)

git init

This creates a hidden folder called .git.

That folder contains:

Every commit
Every branch
The entire history graph
All metadata

Your code files are outside .git.
Your project’s memory lives inside .git.

If .git disappears, Git forgets everything.

Part 4: The Three Places Your Code Can Exist

This is the most important concept in Git.
If you understand this, almost everything else makes sense.

1. Working Directory

This is your normal folder.
You edit files here.
Git is watching, but nothing is saved yet.

2. Staging Area (Index)

This is where you tell Git:

“These specific changes are ready to be recorded.”

Not everything. Just what you choose.

3. Repository (Commits)

This is Git’s permanent history.
Once something is here, it’s part of the timeline.

Git never commits directly from your folder.
It commits from the staging area—because intention matters.

Part 5: Asking Git What It Sees

Before running any command, get used to this:

git status

This tells you:

What changed
What’s staged
What’s not tracked
What Git is waiting for

If Git ever feels confusing, it’s usually because git status wasn’t read.

Part 6: What `git add` Really Does

git add index.html

This does not mean “save forever”.

It means:

“Take the current version of this file and copy it into the staging area.”

You can still edit the file afterward.
The staged version will not change unless you add it again.

This lets you:

Stage only part of your work
Create clean, focused commits

Part 7: Committing (Freezing a Moment)

git commit -m "Add homepage layout"

This creates:

A snapshot
A unique hash (ID)
A permanent history point

Commits cannot be edited.
Git does not erase history—it adds to it.

Think of commits as pages in a journal.
You don’t rip out pages. You write new ones.

Part 8: Commit Messages Are for Humans

Bad messages:

fix
update
stuff

Good messages explain intent:

Fix broken layout on small screens
Add input validation for signup form
Refactor auth logic to simplify flow

Your future self will read this.
So will teammates.
Write like you’re explaining your thinking.

Part 9: Reading History Without Fear

git log

Better:

git log --oneline --graph

This shows:

Commits as nodes
Parent relationships
Branch structure

Git history is a graph, not a straight line.
That’s why merges and branches exist.

Part 10: Branches (The Safest Place to Experiment)

A branch is not a copy of your code.

A branch is:

A movable label pointing to a commit

That’s why creating branches is cheap and encouraged.

git checkout -b feature/settings

Now:

main stays stable
Your work happens safely elsewhere

Each commit moves the branch pointer forward.

Part 11: HEAD (Git’s “You Are Here” Marker)

HEAD simply means:

“This is where you are right now.”

Usually it points to a branch.
Sometimes it points directly to a commit.

Most confusion comes from not knowing where HEAD is.

When lost, ask:

What branch am I on?
What commit does it point to?

Part 12: Merging (Bringing Work Together)

When a feature is ready:

git checkout main
git merge feature/settings

Git tries to combine histories.

Two common outcomes:

Fast-forward merge (simple pointer move)
Merge commit (combining branches)

Both are normal.
History shape is a choice, not a mistake.

Part 13: Merge Conflicts (Not Errors)

A conflict means:

“Git can’t decide for you.”

Git stops.
Marks the file.
Waits.

You:

Open the file
Choose what stays
Remove conflict markers

Then:

git add .
git commit

Conflicts are collaboration points, not failures.

Part 14: Working With Other Humans (Remotes)

A remote repository is just another copy of the same timeline.

git push

“I’m sharing my history.”

git fetch

“Show me new history.”

git pull

“Combine their history with mine.”

If you’re unsure, fetch first.
Nothing breaks from fetching.

Part 15: Undoing Mistakes Calmly

Undo local file changes:

git checkout -- file.txt

Undo a commit safely:

git revert <commit>

Revert creates a new commit that cancels the old one.
History remains truthful.

Part 16: Stashing (Hiding Work Temporarily)

git stash

Git hides uncommitted changes.

git stash pop

Git restores them.

Stash is for interruptions, not long-term storage.

Part 17: Rebase (Editing the Story)

Rebase rewrites commits so history looks clean and linear.

Think of it as editing a draft before publishing.

Golden rule:

Never rebase commits others already have

Part 18: Interactive Rebase (Advanced Control)

git rebase -i HEAD~5

This lets you:

Combine commits
Rename messages
Remove mistakes
Reorder history

This is how clean histories are made.

Part 19: Reflog (The Panic Button)

git reflog

Git remembers:

Every checkout
Every reset
Every mistake

If you think something is lost, reflog usually knows where it went.

Part 20: Habits That Make Git Pleasant

Commit small changes
Write clear messages
Read git status
Don’t force-push shared branches
Respect the timeline

Final Thought

Git is strict, not cruel.

It does exactly what you tell it to do.
Nothing more.
Nothing less.

Once you understand snapshots, staging, and history, Git stops being scary and starts being dependable.

And a dependable memory is one of the most powerful tools a developer can have.

Keep committing.

Before I Write Any Code, I Do This First (A Practical Project Walkthrough)

Dulaj Thiwanka — Mon, 26 Jan 2026 07:41:35 +0000

Most people believe software projects fail because of bad code.

That’s rarely true.

They fail because:

The problem wasn’t clear
The scope was too big
Decisions were made too late
Structure was an afterthought

I used to jump straight into coding. It felt productive. It felt exciting.

But I kept hitting the same wall:

Rewriting things
Adding features endlessly
Losing motivation halfway
Abandoning projects that should have worked

Eventually, I realized something simple but uncomfortable:

If I’m confused while building, it’s because I was confused before I started.

So now, before I write any code, I structure the project carefully. This article shows exactly how, step by step, using a real project example—no tech background required.

The Example Project We’ll Use

To keep this real and relatable, let’s use a practical example:

A very simple expense-tracking app
(Not a startup, not a “next big thing” — just something useful.)

This makes it easier to see how each step affects real decisions.

Step 1: I Slow Down and Kill the “Build Something” Urge

The first thing I do is nothing.

No editor.
No framework.
No repo.

Why?

Because excitement is dangerous. When you’re excited, you say yes to everything—and regret it later.

Instead, I open a blank document and write one sentence:

“What problem am I trying to solve?”

For our example, the wrong answer would be:

“People need a finance app”

The better answer is:

“People don’t know where their money goes, and most tracking apps feel too complex to use daily.”

This sentence becomes the foundation of everything else.

Step 2: I Remove All Technical Language on Purpose

At this stage, technical words are banned.

No:

Database
API
Backend
UI
Stack

Only human language.

If I can’t explain the project without tech words, it means I don’t understand it well enough.

This step forces clarity—and clarity is power.

Step 3: I Choose a Single, Specific User

This is where many projects quietly fail.

I don’t build for:

“Everyone”
“All users”
“The market”

I build for one type of person.

For our expense app:

“A busy person who wants to quickly log expenses without thinking.”

This single decision eliminates dozens of future arguments:

Do we need advanced charts? → No
Do we need onboarding tutorials? → Minimal
Do we need customization? → Probably not

When the user is clear, complexity drops.

Step 4: I Write the User’s Day as a Story

Now I imagine the project in real life.

I write something like this:

“It’s the end of the day.
The user bought lunch and paid for transport.
They open the app.
They immediately see an ‘Add Expense’ option.
They enter amount and category.
They see today’s total spending.
They close the app feeling calm and aware.”

This story does several things:

It removes unnecessary features
It highlights the main action
It shows what really matters

If something doesn’t appear in the story, it probably doesn’t belong in version one.

Step 5: I Define the Core Promise of the Project

Now I write one sentence called the core promise:

“This app helps you quickly record expenses and see how much you spent today.”

Not five promises.
Not a feature list.

Just one promise.

Every future decision must support this sentence.
If it doesn’t, it waits.

Step 6: I Ruthlessly Cut Features (Before They Exist)

This is uncomfortable—but critical.

I create a section called:

“Things This Project Will NOT Do (Yet)”

For our example:

No monthly budgeting
No charts or graphs
No bank syncing
No user accounts
No cloud backup
No AI insights

Writing this down feels risky, but it creates focus and peace.

Instead of feeling like I’m behind, I feel intentional.

Step 7: I Break the Project Into Mental Building Blocks

Now—and only now—I think about structure.

Not code.
Not files.

Just parts.

For the expense tracker:

Input expenses
Save expenses
Show today’s total
Basic settings

That’s the entire system.

If I can’t describe the project in 4–6 blocks, it’s too big.

Step 8: I Sketch the Flow (Very Rough)

I might draw:

Boxes on paper
Arrows between screens
Or just bullet points

Example flow:

Home → Add Expense → Back to Home
Home → Today’s Summary

No design.
No polish.

Just logic.

This step catches problems early—when fixing them is cheap.

Step 9: I Write a “Project Blueprint” Document

Before coding, I always write this. Always.

Here’s what it looks like for our example:

Project Name

Simple Expense Tracker

Problem

People struggle to track daily spending because existing apps feel complex.

Target User

Busy individuals who want fast, low-effort expense tracking.

Core Promise

Log expenses quickly and see daily totals.

Main Actions

Add expense
View today’s spending

Out of Scope

Budgets, charts, syncing, accounts, analytics

Success Looks Like

A user can add an expense in under 10 seconds without confusion.

This document is my anchor.

Future me will thank present me for this.

Step 10: Only Now Do I Touch Technology

Only after everything above do I ask:

Is this web or mobile?
How simple can the tech be?
What’s the least complex solution?

Because now:

Overengineering feels silly
Decisions are obvious
Trade-offs are clear

Technology becomes a tool—not the driver.

Why This Process Works So Well

It looks slow.
It feels boring at first.

But it saves enormous time later by:

Reducing rewrites
Preventing scope creep
Making decisions easier
Increasing the chance of finishing

You trade early excitement for long-term momentum.

This Isn’t Just for Developers

This approach works for:

SaaS ideas
Freelance projects
Content platforms
Newsletters
Startups
Personal side projects

The pattern is universal:
Clarity → Structure → Execution

Final Thought

Writing code feels productive.

But knowing exactly what you’re building is what actually gets projects finished.

Now, whenever I feel stuck, I ask myself:

“Did I skip the thinking part?”

Most of the time, the answer is yes.

So I go back—before the code.

New Year, New You Portfolio Challenge Presented by Google AI

Dulaj Thiwanka — Thu, 08 Jan 2026 04:19:12 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me:

Hi! 👋 I’m Dulaj Thiwanka, a passionate and dedicated Full Stack Developer with a strong foundation in building user-centric and scalable web applications. I graduated in Information Technology and specialize in technologies like React, Node.js, cloud services, and modern development tools. I enjoy solving complex problems, creating meaningful software solutions, and continuously expanding my skills—especially in areas like AI, prompt engineering, and cloud technologies.

Beyond coding, I’m an avid learner and explorer—whether it’s new tech, creative problem-solving, or connecting with others who share similar goals. My portfolio showcases the projects I’ve built, from full-stack applications and IoT systems to RESTful APIs and dynamic user interfaces, with the aim of expressing my growth, versatility, and commitment to impactful tech. Through this portfolio, I hope to communicate not just what I can do, but what I’m eager to create next—whether that’s collaborating on meaningful projects, contributing to open-source, or pushing the boundaries of what technology can achieve.

Portfolio:

How I Built It:

This project was built using React with ViteJS for a fast, modern development experience and optimized performance. Tailwind CSS was chosen to create a clean, responsive, and consistent UI while allowing rapid iteration and customization.

From a design perspective, I focused on simplicity, usability, and scalability—keeping the interface minimal while ensuring smooth user interaction and clear visual hierarchy. Components were structured to be reusable and maintainable, following best practices in modern frontend development.

For AI integration, I embedded the Google Gemini API to enhance functionality with intelligent, context-aware responses. This allowed the application to demonstrate real-world AI usage, combining frontend performance with powerful generative AI capabilities.

Overall, my development process emphasized modular architecture, performance optimization, and seamless AI integration, resulting in a polished and future-ready application.

What I'm Most Proud Of:

I’m most proud of successfully integrating Google’s Gemini API into a modern React application and making AI feel both accessible and practical within a clean user experience. Turning a powerful generative AI tool into something intuitive for users was a key achievement.

From a technical standpoint, I’m proud of the performance and structure of the application—using ViteJS for fast builds, React component reusability, and Tailwind CSS for a responsive, visually consistent design. The project maintains a good balance between functionality and simplicity.

I’m also proud of the overall development workflow, from planning the UI and component architecture to embedding AI features in a scalable way. This project represents my growth as a developer and my ability to combine modern frontend technologies with real-world AI integration to build meaningful, future-ready applications.

JWT vs OAuth: Why Everyone Argues, and Almost Everyone Is Slightly Wrong

Dulaj Thiwanka — Thu, 08 Jan 2026 04:06:38 +0000

JWT vs OAuth: Why Everyone Argues, and Almost Everyone Is Slightly Wrong

At some point, usually after your first “secure” API ships to production, a quiet dread appears.

You open your auth middleware.
You stare at a token.
You wonder if you actually understand why this works.

Then the question arrives:

“Are we using JWT… or OAuth?”

The problem is not the question.
The problem is that the internet answers it like a shouting match instead of a conversation.

So let’s have the conversation.

Why This Topic Refuses to Stay Simple

JWT and OAuth live in the same ecosystem:

both deal with tokens
both show up in authentication flows
both are involved in “secure APIs”

That overlap tricks people into thinking they solve the same problem.

They don’t.

They solve different problems at different layers, and the confusion only exists because we keep collapsing layers to move faster.

Speed is fun. Security remembers everything.

JWT: A Token That Refuses to Be Forgetful

A JSON Web Token (JWT) is a self-contained, verifiable data package.

It says:

“Here are some claims.
Here’s proof they haven’t been altered.”

Nothing more. Nothing less.

A JWT has three parts:

header.payload.signature

The header says how the token was signed
The payload contains claims (user ID, roles, expiration, etc.)
The signature proves integrity

The Seduction of Statelessness

JWT’s biggest selling point is statelessness.

The server doesn’t remember sessions.
It just verifies math.

That means:

no session store
no sticky sessions
easy horizontal scaling

This is why JWT exploded alongside microservices and cloud-native systems.

But stateless does not mean consequence-free.

The Trade-Off JWT Makes (And Never Warns You About)

JWT trades control for performance.

Once issued:

the server can’t easily revoke it
the token lives until it expires
whoever has it is the user

This is fine when:

tokens are short-lived
scopes are narrow
refresh strategies are sane

It’s dangerous when:

tokens last days or weeks
secrets leak into payloads
JWT is treated like a magical session replacement

JWT is a sharp knife.
It cuts beautifully.
It does not ask permission.

OAuth: The Art of Delegated Trust

OAuth is not about identity.

OAuth is about permission.

It exists to answer one specific question:

“Is this application allowed to access that resource on behalf of this user?”

That’s it.
No identity. No emotions. Just boundaries.

OAuth introduces formal roles:

Resource Owner – the user
Client – the application
Authorization Server – issues tokens
Resource Server – protects data

This structure feels heavy because trust is heavy.

Why OAuth Feels Complicated (Because It Is)

OAuth wasn’t designed for:

small apps
solo projects
“just log the user in”

It was designed for:

ecosystems
third-party access
companies that do not trust each other (correctly)

OAuth assumes:

multiple apps
limited permissions
tokens that can be revoked
scopes that matter

It’s verbose because ambiguity is dangerous.

The Moment Everyone Gets Fooled: “Login With Google”

Here’s the twist that breaks brains:

When you “log in” with Google, you’re not using OAuth alone.

You’re using OpenID Connect (OIDC).

OIDC is an identity layer on top of OAuth 2.0.

OAuth says:

“This app may access this resource.”

OIDC adds:

“And here is who the user actually is.”

Without OIDC, OAuth does not authenticate humans.
It authorizes software.

How JWT, OAuth, and OIDC Actually Work Together

This is the real-world flow most systems use, even if they don’t realize it:

User authenticates via OIDC
Authorization server validates identity
An access token is issued
That access token is often a JWT
APIs verify the JWT signature locally

JWT becomes the container.
OAuth defines who may receive it.
OIDC defines who the user is.

This is not redundancy.
This is layering.

Access Tokens vs Refresh Tokens (Where Many Breaches Begin)

Not all tokens are equal.

Access tokens
- short-lived
- sent with every request
- frequently JWTs
Refresh tokens
- long-lived
- never sent to APIs
- used only to obtain new access tokens

If your refresh token leaks, you have a real problem.

If your access token leaks, expiry limits the blast radius.

Security is about containing damage, not preventing mistakes.

When JWT Alone Is Enough

JWT-only authentication is reasonable when:

you control the entire system
users don’t need third-party login
permissions are simple
tokens expire quickly

This is common in:

internal tools
early-stage products
mobile apps with a single backend

JWT shines in closed worlds.

When OAuth/OIDC Is Worth the Pain

OAuth and OIDC earn their keep when:

users expect social login
multiple clients exist (web, mobile, partners)
APIs are exposed externally
access must be scoped and revocable

OAuth is not overengineering.
It’s honest engineering.

Persistent Myths That Refuse to Die

“JWT is more secure than OAuth”
They solve different problems. Stop comparing them.

“OAuth replaces JWT”
OAuth frequently uses JWT as its token format.

“JWT payloads are private”
They are readable. Assume visibility.

“Stateless means simpler”
Stateless means fewer knobs when things go wrong.

The Mental Model That Actually Works

If nothing else sticks, let this one stick:

JWT → how claims are packaged
OAuth → who may access what
OIDC → who the user is

Once you separate those layers, the noise fades.

Final Thought: Security Is Memory

Security systems are not about clever code.
They are about remembering past decisions under pressure.

JWT remembers claims.
OAuth remembers permissions.
OIDC remembers identity.

Confusion happens when we forget why each one exists.

Clarity is not optional here.
It’s the difference between a clean audit and a long incident report.

And incident reports are never written at pleasant hours.

Read on Medium : Medium Article

Vibe Coding: Shipping Code While the Brain Is Still Happy

Dulaj Thiwanka — Wed, 10 Dec 2025 09:40:20 +0000

You know that moment when everything clicks?

The editor feels fast.
The idea is clear.
You’re not googling every 30 seconds.
The code is flowing and you don’t want to stop.

That’s the vibe.

Vibe Coding is leaning into that state instead of fighting it with over-engineering, premature rules, and 12 tabs of documentation you didn’t need yet.

What Is Vibe Coding (In Plain Dev Terms)

Vibe Coding isn’t a framework.
It’s not “cowboy coding”.
It’s not an excuse to ship garbage.

It’s a way of working where you optimize for:

Flow
Momentum
Mental clarity
Enjoyment

You write code that makes sense right now, and you trust yourself to make it better later.

The Core Things That Make Up Vibe Coding

Think of Vibe Coding as a small toolkit, not a philosophy lecture.

1. Momentum Over Perfection

If you stop every 5 minutes to “do it properly”, you kill the idea before it’s alive.

Get it working first.
Make it pretty later.

2. Low Cognitive Load

Your brain has limited RAM.

Vibe Coding means:

Fewer abstractions early
Fewer files at the start
Obvious names over clever ones
Straight lines instead of fancy patterns

Simple code = more brain space for the actual problem.

3. Feedback Loops That Are Instant

Fast feedback keeps the vibe alive.

Hot reload
Live preview
Console logs (yes, really)
Visual output over theory

If feedback is slow, motivation dies quietly.

4. Code That Feels Readable

Not “enterprise clean”.
Not “leetcode clever”.

Just:

“Yeah… I get what this does.”

Readable code keeps you in flow longer.

5. Emotional Awareness (Underrated Skill)

Vibe Coding includes noticing:

When you’re tired
When you’re forcing it
When flow is gone

Pushing through bad mental states usually creates bad code.

Stopping is a skill.

How to Actually Practice Vibe Coding (Step-by-Step)

This is the part most articles skip.

Step 1: Start Before You Feel Ready

If you wait for the perfect plan, you’ll never start.

Open the editor.
Create the file.
Write the ugly first version.

Motion creates clarity.

Step 2: Build the “Stupid Version” First

Ask:

“What’s the dumbest possible version that works?”

Hardcode things.
Duplicate code.
Ignore edge cases.

You’re sketching, not painting.

Step 3: Stay in One Mental Mode

Don’t mix:

Designing
Optimizing
Refactoring
Naming perfectly

Pick one mode.
Vibe Coding mode = build mode.

Step 4: Let Patterns Appear Naturally

Once you see:

Repeated logic
Similar components
Copy-paste growing

That’s your signal to refactor.

Refactoring before patterns exist is just guessing.

Step 5: Refactor in Short, Focused Bursts

Refactor after momentum, not during it.

Rename things
Extract functions
Clean files
Add types/tests

Then stop.
Don’t spiral.

Step 6: Lock It Down Before Shipping

Vibe Coding ends before production.

Before shipping:

Handle edge cases
Add validation
Clean obvious messes
Remove debug junk

Vibe ≠ reckless.

Things That Help the Vibe (Surprisingly Practical)

Environment Things

Editor theme you enjoy
Font that doesn’t strain your eyes
Minimal UI clutter
Comfortable keyboard/layout

Your environment affects your thinking more than you think.

Workflow Things

One task at a time
One screen if possible
Notifications off
Clear goal for the session

Vibe dies when attention fragments.

Mental Things

Accept messy first drafts
Don’t judge code too early
Don’t compare mid-work
Treat coding like writing, not math

Drafts are allowed.

Where Vibe Coding Works Best

Vibe Coding shines in:

Side projects
MVPs
Hackathons
UI-heavy apps
Learning new frameworks
Creative experiments

It struggles in:

Safety-critical systems
Compliance-heavy apps
Massive legacy codebases

Context matters. Always.

Vibe Coding With AI (Use Carefully)

AI is amazing for:

Boilerplate
Scaffolding
Explaining errors
Unblocking flow

AI is bad at:

Architecture decisions
Product judgment
Knowing your context

Use AI to support the vibe, not replace thinking.

Common Mistakes People Make

Never refactoring
Using “vibe” as an excuse for chaos
Shipping prototypes to production
Ignoring tests forever
Coding while exhausted and angry

Vibe Coding still requires responsibility.

Final Thought

Vibe Coding is about respecting how humans actually think.

Flow beats force.
Momentum beats over-planning.
Clarity beats cleverness.

Write the code that lets you keep going.

Clean it later.
Ship it when it’s ready.
And enjoy the process — that’s usually where the best ideas show up.

Follow Me : https://medium.com/@dulthiwanka2015

Using Console Colors with Node.js: A Complete Guide for Cleaner, Smarter Terminal Output

Dulaj Thiwanka — Fri, 14 Nov 2025 10:18:14 +0000

Terminal output is the heartbeat of backend developers. Whether you're debugging a stubborn API issue, running background jobs, or building a CLI tool, the console is your most constant companion. Adding color to that output transforms a flood of text into an organized dashboard for your brain.

Node.js makes this surprisingly easy. This guide digs into how console colors really work, common libraries, advanced tricks, and practical patterns for using them effectively.

How Console Colors Work Under the Hood

Terminals support something called ANSI escape codes, tiny embedded instructions inside strings that change how text appears. These color codes have been around since the early days of UNIX.

A simple example looks like this:

\x1b[31mHello\x1b[0m

\x1b means ESC (escape).
[31m means “switch to red”.
[0m means “reset styles”.

Node.js outputs this directly to your terminal when you call:

console.log("\x1b[31mThis is red\x1b[0m");

This gives you bare-metal control, which is useful once you understand the pattern.

The Core ANSI Color Codes (Reference)

Foreground colors:

Black: \x1b[30m
Red: \x1b[31m
Green: \x1b[32m
Yellow: \x1b[33m
Blue: \x1b[34m
Magenta: \x1b[35m
Cyan: \x1b[36m
White: \x1b[37m

Background colors:

Red background: \x1b[41m
Green background: \x1b[42m
Yellow background: \x1b[43m
Blue background: \x1b[44m
Magenta background: \x1b[45m
Cyan background: \x1b[46m

Style modifiers:

Bold: \x1b[1m
Dim: \x1b[2m
Italic: \x1b[3m
Underline: \x1b[4m

Reset:

Reset all: \x1b[0m

These codes stack, which lets you do things like:

console.log("\x1b[1m\x1b[33mBold Yellow\x1b[0m");

It’s low-level, but powerful.

Using Chalk for Cleaner Syntax and Modern Features

Working with raw escape codes is like writing HTML inline styles everywhere. Chalk fixes that with a clean API.

Install:

npm install chalk

Use:

import chalk from 'chalk';

console.log(chalk.red('Error'));
console.log(chalk.green('Success'));
console.log(chalk.yellow('Warning'));
console.log(chalk.bold.blue('Info message'));

Chalk Highlights

Chalk gives you three key advantages:

Cleaner syntax
No escape code juggling.
Automatic color support detection
Some terminals don’t support color. Chalk gracefully downgrades.
Nested & chained styling
Chalk handles resets for you.

console.log(chalk.bgRed.white.bold(" Critical System Failure "));

Extended Color Support

Chalk supports 256-color and TrueColor (16 million colors):

console.log(chalk.hex('#ff8800')('Orange heading'));
console.log(chalk.rgb(150, 120, 50)('Custom tone'));

This is useful when designing CLI tools that need branding or visual structure.

Using `colors` for Inline Style Shortcuts

Install:

npm install colors

Use:

import 'colors';

console.log("Updated successfully".green);
console.log("Something went wrong".red.bold);
console.log("Check configuration".yellow.underline);

Caveat: Prototype Modification

This library modifies the String.prototype.

Great for small scripts.
Not ideal for large or shared codebases.

Using `kleur` for a Lightweight Alternative

If you want Chalk-like features with a smaller footprint:

Install:

npm install kleur

Use:

import kleur from 'kleur';

console.log(kleur.red('Error'));
console.log(kleur.bold().green('Success'));
console.log(kleur.bgYellow().black('Warning'));

kleur is fast and tiny, good for performance-sensitive CLI tools.

Formatting Output with `console` Methods

Node gives you some built-in variations:

console.error(chalk.red("Fatal error"));
console.warn(chalk.yellow("Warning"));
console.info(chalk.blue("Info"));
console.log(chalk.green("Done"));

Each has a semantic purpose:

console.error() prints to stderr
console.log() prints to stdout

This matters when scripting or logging to other processes.

Detecting If Colors Are Supported

Some environments strip ANSI codes:

Docker logs
CI systems
Windows terminal (older versions)
File exports

Chalk makes detection easy:

if (!chalk.supportsColor) {
  console.log("Your terminal doesn't support color");
}

Manual detection:

const colorSupported = process.stdout.isTTY;

Good CLI tools gracefully degrade.

Creating a Reusable Logger with Colors

A small logger can unify styles for an entire project:

import chalk from 'chalk';

const log = {
  info: (msg) => console.log(chalk.blue("[INFO]"), msg),
  success: (msg) => console.log(chalk.green("[SUCCESS]"), msg),
  warn: (msg) => console.log(chalk.yellow("[WARN]"), msg),
  error: (msg) => console.log(chalk.red("[ERROR]"), msg),
};

log.info("Server started");
log.success("Database connected");
log.warn("High memory usage");
log.error("Failed to load config");

This gives your project consistent, structured output.

Tips for Designing Color Logic

A few guidelines from writing CLI tools:

• Use color for meaning, not decoration.
• Reserve red for actual errors.
• Yellow works best for non-critical warnings.
• Magenta and cyan help differentiate categories.
• Don’t overload a single line with too many styles.
• Test output in multiple terminals.

A good rule: if every line is colorful, none of them matter.

Final Thoughts

Colored console output is more than an aesthetic trick. It’s a tight feedback loop for developers, a way of turning raw text into a readable system of symbols. Once you understand ANSI codes and the available Node.js libraries, you can design output that actually helps you think.

This small skill pays off when you build tools, monitor logs, debug servers, or shape your own development workflow. Exploring this further even opens paths into advanced CLI UI frameworks like Ink, Commander.js integration, loading spinners, progress bars, and full interactive terminal interfaces.

Color is just the beginning.

Understanding the MERN Stack for Beginners

Dulaj Thiwanka — Tue, 11 Nov 2025 04:24:29 +0000

The MERN Stack is one of the most popular and practical ways to build modern web applications. If you're interested in becoming a full-stack developer, learning MERN gives you the skills to create complete apps — everything from the visual interface to the database behind the scenes.

And the best part? You only need to know JavaScript.

This guide expands your understanding step-by-step, keeping things friendly, practical, and beginner-focused.

What is the MERN Stack?

MERN is made up of four core technologies:

Letter	Technology	What It Does
M	MongoDB	Stores your application's data
E	Express.js	Handles backend logic and API routing
R	React.js	Builds the user interface (UI)
N	Node.js	Runs JavaScript on the server

These four pieces work together to create a complete web app.

Why Learn the MERN Stack?

Uses one programming language — JavaScript — everywhere.
Easy to scale and great for real-world apps.
Huge community and lots of free learning resources.
Used by startups, tech companies, and freelancers.

If your goal is to build a portfolio that stands out, MERN projects are perfect.

MERN Architecture (How Everything Communicates)

Simple Example:

User clicks Add Task → React sends task to backend → Backend saves it in MongoDB → MongoDB stores → Backend sends confirmation → React updates screen.

This cycle is the heart of MERN.

Breakdown of Each Technology

1. MongoDB — The Database

MongoDB stores data as documents (similar to JSON):

{
  "name": "Alice",
  "age": 22,
  "isStudent": true
}

This format makes MongoDB easy to use with JavaScript.

2. Express.js — Handling APIs

Express helps you create routes like:

app.get('/users', (req, res) => {
  res.send('List of users');
});

Express receives requests, processes logic, and sends responses.

3. React.js — Building the UI

React focuses on creating components.

function Welcome() {
  return <h1>Welcome to MERN Learning!</h1>;
}

React updates only the parts of the page that change — making apps feel fast.

4. Node.js — Runs Your Backend

Node allows JavaScript to run outside the browser.

node server.js

This starts your backend server.

Typical MERN Folder Structure

project/
│
├── client/           → React (Frontend)
│   ├── src/
│   └── package.json
│
├── server/           → Node + Express (Backend)
│   ├── models/       → MongoDB schemas
│   ├── routes/       → API endpoints
│   ├── server.js
│   └── package.json
│
└── README.md

Separating frontend and backend keeps your project clean.

Core Concepts You Must Learn

1. REST APIs

Your frontend talks to your backend using HTTP requests like:

GET (read data)
POST (send data)
PUT (update data)
DELETE (remove data)

2. JSON Format

This is how data travels between frontend and backend.

3. State Management in React

Examples: useState, useEffect hooks.

Basic CRUD Example (Create, Read, Update, Delete)

Backend Route Example:

// Create Task
app.post('/tasks', async (req, res) => {
  const newTask = new Task({ text: req.body.text });
  await newTask.save();
  res.send('Task saved');
});

Frontend Fetch Example:

fetch('/tasks', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ text: 'Learn MERN' })
});

Deploying a MERN App

You can host:

Frontend on Vercel / Netlify
Backend on Render / Railway
Database on MongoDB Atlas

This lets your project become public — great for portfolios.

Learning Roadmap (Beginner Friendly)

Start with:

JavaScript Basics (functions, arrays, objects)
React Basics (components, props, hooks)
Node + Express (API routes, server setup)
MongoDB (CRUD operations)
Build small projects (notes app, messenger, to-do app)

Practice is everything.

Final Thoughts

The MERN stack is powerful, modern, and approachable — perfect for anyone learning full-stack development.

Take it step-by-step, build consistently, and focus on understanding how data flows.

You're not just learning tools — you're learning how to build real applications.

Happy coding! 🚀

ChatGPT Go Is Now in Sri Lanka — Here’s How It Stacks Up Against Plus, Pro & Free

Dulaj Thiwanka — Sat, 11 Oct 2025 11:40:26 +0000

OpenAI’s ChatGPT Go has officially reached Sri Lanka, giving users access to GPT-5 and an upgraded AI experience for just $5/month (~LKR 1,650). Positioned between the Free and Plus plans, it’s designed for people who want more AI power without paying premium pricing.

This post dives into what Go offers, how it compares to other subscriptions, and why it might be perfect for you.

💸 Pricing — Affordable AI Access

Region	Price
Sri Lanka	$5 USD/month (~LKR 1,500)
India	₹399/month (~$4.60)

Compared to Plus ($20/month) or Pro ($200/month), this is a significant discount for daily users, students, and freelancers.
and for this counties also (Afghanistan,Myanmar,Bangladesh,Indonesia,Nepal,Thailand,Bhutan,Laos,Pakistan,Timor-Leste (East Timor),Brunei,Darussalam,Malaysia,Philippines,Vietnam,Cambodia,Maldives)

✅ Key Features of ChatGPT Go

ChatGPT Go offers a solid feature set designed for productivity:

Access to GPT-5: Get the latest model’s improved reasoning, creativity, and understanding.
Expanded messaging & uploads: Send more messages, upload more files, and keep your conversations longer.
Expanded & faster image creation: Generate images quickly, perfect for design drafts, social media, or learning.
Longer memory & context: The model remembers more of your conversation, reducing repetitive prompts.
Limited Deep Research: Access some advanced tools, though heavier research capabilities remain in higher tiers.
Projects, Tasks & Custom GPTs: Organize workflows, automate tasks, and create GPT instances tailored to your needs.

⚠️ Available only in certain regions, and limits still apply.

🥊 Comparing Subscription Tiers

Tier	Price	Features	Best For
Free	$0	Basic GPT access, limited messages, forgetful context	Casual users / trial
ChatGPT Go	$5	GPT-5, expanded messages/uploads, faster images, longer memory, projects & tasks	Students, devs, freelancers, daily AI users
Plus	$20	Priority access, full GPT-4/5, web browsing, voice, tools	Professionals, content creators, power users
Pro	$200	“Unlimited” usage, agents, high compute, business workflows	Researchers, startups, enterprises

Bottom line: Go is enough for most creative, coding, or productivity workflows. Only heavy automation or deep research will need Plus or Pro.

🌍 Regional Availability

Available in Sri Lanka and India
Not yet in EU, US, or UK
OpenAI labels this as “limited regions”, meaning rollout might expand gradually

Sri Lanka is now among the first countries outside India to access this budget AI tier — a huge win for local developers and creators.

💡 Use Cases: How You Can Benefit from Go

Students & Learners: Get essay help, coding explanations, and research assistance without hitting Free limits.
Freelancers & Developers: Draft content, debug code, generate images, or create small AI-powered tools.
Creators: Generate social media posts, storyboards, or illustrations with faster image creation.
Small Teams: Organize projects and tasks, automate repetitive workflows using custom GPTs.

🔍 Feature Deep Dive

Expanded Messaging & Uploads

Go allows 10× more messages than Free and lets you upload files such as PDFs, images, and CSVs. Perfect for projects that require reference materials or collaborative work.

Image Generation

With Go, images are created faster and in higher volumes, enabling mockups, design drafts, or quick visual brainstorming without hitting Plus limits.

Memory & Context

The longer memory means your AI assistant can recall past instructions across multiple conversations, reducing repetitive prompts and improving productivity.

Projects, Tasks & Custom GPTs

Organize your AI workflows in projects, assign tasks to custom GPTs, and build tailored models for specific needs — all part of the Go plan. This feature is great for freelancers, students, and hobby developers experimenting with AI automation.

⚡ Practical Tips & Tricks

Batch your prompts: Take advantage of expanded message limits to complete multi-step tasks efficiently.
Use uploads strategically: Combine files into single uploads to maximize the memory benefit.
Custom GPTs: Start simple — create one GPT for each major task (e.g., content drafting, coding helper) and expand gradually.
Mind usage limits: Even with Go, extreme workloads may require Plus for faster access during peak hours.

🔮 Future Outlook

OpenAI may expand Go to other regions soon. The features in Go could also be gradually upgraded as user adoption grows. For Sri Lankan users, this is the first time a budget tier offers GPT-5 with meaningful enhancements — a huge step for AI accessibility.

🎯 Should You Upgrade to Go?

Yes, if you:

Hit Free tier message or upload limits often
Need longer memory & context for workflows
Want GPT-5 access without the $20/month commitment

Stick with Free if you:

Use AI casually or occasionally
Don’t need expanded memory or faster images

Go is perfect for students, developers, content creators, and small teams in Sri Lanka looking for affordable, practical AI power.

Conclusion

ChatGPT Go is OpenAI’s smartest low-cost tier yet. It balances affordability, functionality, and access to the latest AI models. For Sri Lanka, this is a watershed moment — no VPNs, no workarounds, just $5/month for GPT-5 power.

If you’re serious about AI productivity, Go is worth trying immediately.

Get Your Free .is-a.dev Subdomain: Step-by-Step Guide for Developers

Dulaj Thiwanka — Mon, 29 Sep 2025 05:03:17 +0000

Are you a developer looking for a clean, professional, and free domain for your portfolio, projects, or personal site?
Meet .is-a.dev — a community-driven service that gives developers free subdomains like:

yourname.is-a.dev
project.is-a.dev
portfolio.is-a.dev

The best part? You don’t need to buy a domain or configure a registrar — you just submit a small JSON file via GitHub.

In this guide, you’ll learn:

✅ What .is-a.dev is
✅ Why developers use it
✅ Rules you need to know
✅ Step-by-step setup (with examples)
✅ How to update or delete it later

Let’s get rolling 🚀

🧩 What Is `.is-a.dev`?

.is-a.dev is an open-source service that gives developers free subdomains for personal or software-related projects. Registration happens via a GitHub pull request to their public repo.

You can use it for:

🌐 Portfolios
🛠 Dev blogs
💻 GitHub Pages
📦 Vercel / Netlify sites
🚀 APIs & side projects

➡️ Repo: github.com/is-a-dev/register
➡️ Docs: https://docs.is-a.dev

Because it’s listed in the Public Suffix List (PSL), many platforms treat it like a real top-level domain — meaning fewer restrictions.

✅ DNS Record Types You Can Use

.is-a.dev supports the most common DNS records:

Record	Use Case
A / AAAA	VPS, server hosting
CNAME	GitHub Pages, Vercel, Netlify, etc
MX	Email routing
TXT	Verification & configs
URL	Redirects
SRV / TLSA	Advanced setups

⚠️ NS (nameserver delegation) is only allowed in certain approved cases, and only if your subdomain has existed for 30+ days.

🛠 Step-by-Step: Get Your `.is-a.dev` Subdomain

✅ 1. Prerequisites

You’ll need:

A GitHub account
A site or project to point to (or plan to host one)
The DNS record type you want to use (e.g. CNAME or A)

✅ 2. Fork the Register Repo

Go to:
🔗 https://github.com/is-a-dev/register

Click Fork to copy it to your GitHub account.

✅ 3. Create Your JSON File

Inside your fork:

Go to the domains/ folder
Click Add file → Create new file
Name it after the subdomain you want, for example:

   yourname.json

→ This becomes yourname.is-a.dev

✅ Rules:

2–64 characters
lowercase letters, numbers, and dashes only

Now add the JSON data.

Example for GitHub Pages:

{
  "owner": {
    "username": "your-github-username"
  },
  "records": {
    "CNAME": "yourgithubusername.github.io"
  }
}

Example for VPS / IP hosting:

{
  "owner": {
    "username": "your-github-username"
  },
  "records": {
    "A": ["123.45.67.89"]
  }
}

Commit the file.

✅ 4. Open a Pull Request (PR)

After saving, GitHub will prompt you to Open a Pull Request.

In the PR description:

Complete the checklist
Confirm your project is dev-related
Submit the PR

That’s it — now the maintainers will review it.

⏳ Typical approval time: 24–72 hours

✅ 5. Wait for Merge & Test Your Domain

Once merged:

DNS propagates within minutes (sometimes a bit longer)
Visit yourname.is-a.dev to check

If you still see the .is-a.dev homepage:

Refresh / clear cache
Flush DNS (if needed)

For GitHub Pages users, enable “Enforce HTTPS” in repo settings.

🔁 Need to Update or Delete Later?

Just edit or delete your .json file in your fork and submit another PR.

✅ Example changes:

Update IP
Switch from CNAME to A record
Add TXT or MX
Remove the domain entirely

🧠 Example Walkthrough

Let’s say Alice wants alice.is-a.dev for her GitHub Pages site.

She creates:

domains/alice.json, with:

{
  "owner": {
    "username": "alice"
  },
  "records": {
    "CNAME": "alice.github.io"
  }
}

She opens a PR → it's merged → DNS goes live →
✅ alice.is-a.dev now points to her site!

✅ Why Developers Love `.is-a.dev`

✅ Free forever
✅ Clean, developer-friendly branding
✅ Works with GitHub Pages, Vercel, Netlify, etc
✅ Supports various DNS records
✅ Full control through JSON and GitHub

Perfect if you don’t want to register/pay for your own .com, .dev, .io, etc.

🛠 Common Issues & Fixes

Problem	Solution
PR not merged yet	Wait patiently / check for comments
Domain shows default page	Browser or DNS cache → clear it
HTTPS not working	Enable HTTPS in hosting settings
Want NS records	Only allowed after 30 days with justification
Nested domains	Allowed if you own the parent (`blog.alice.is-a.dev`)

✨ Final Thoughts

If you want a professional-looking domain for your dev presence — without buying one — .is-a.dev is a fantastic solution.

You control the DNS.
It’s simple to manage via GitHub.
And the process takes less than 10 minutes.

Forem: Dulaj Thiwanka

What 24 Hours of Non-Stop Coding Taught Me About Being a Developer

The Challenge

The Stack (No Time to Experiment)

Hour 1–2: The Most Dangerous Phase

Hour 3–8: Backend Flow State

Hour 9–16: Where Everything Started Slipping

Hour 17–22: The Mental Wall

Hour 23: A Shift in Mindset

Hour 24: Done… Not Perfect, But Done

The Final App

What This Actually Taught Me

1. I Overthink Way More Than I Realize

2. Simplicity Is Not “Basic” — It’s Strategic

3. Perfection Is Just a Delay Mechanism

4. Execution Is a Skill

5. Finishing Is Rare

Would I Do It Again? 🤔

If You’re Still Reading…

The Ultimate Guide to Browser Storage: LocalStorage, IndexedDB, Cookies, and More

Why Browser Storage Exists

1. Local Storage

Basic Usage

Storage Scope

Common Use Cases

2. Session Storage

3. Extension Storage

storage.local

storage.sync

storage.session

Example

Common Use Cases

4. IndexedDB

Key Concepts

Database

Object Store

Index

Transaction

Example

Advantages

Real-World Usage

5. Cookies

Characteristics

Example

Security Flags

HttpOnly

Secure

SameSite

Use Cases

6. Cache Storage

Example

Benefits

Common Strategies

Cache First

Network First

Stale While Revalidate

7. Storage Buckets

Comparison of Browser Storage Options

How Modern Web Apps Use Browser Storage

Final Thoughts

Git, Explained

Part 1: Why Git Exists (A Very Human Problem)

Part 2: The Mental Model That Changes Everything

Part 3: Creating a Repository (Where Memory Begins)

Part 4: The Three Places Your Code Can Exist

1. Working Directory

2. Staging Area (Index)

3. Repository (Commits)

Part 5: Asking Git What It Sees

Part 6: What git add Really Does

Part 7: Committing (Freezing a Moment)

Part 8: Commit Messages Are for Humans

Part 9: Reading History Without Fear

Part 10: Branches (The Safest Place to Experiment)

Part 11: HEAD (Git’s “You Are Here” Marker)

Part 12: Merging (Bringing Work Together)

Part 13: Merge Conflicts (Not Errors)

Part 14: Working With Other Humans (Remotes)

Part 15: Undoing Mistakes Calmly

Part 16: Stashing (Hiding Work Temporarily)

Part 6: What `git add` Really Does