DEV Community: Rolan Lobo

I Built a Chat App That Deletes Itself (Because I Was Bored at 2am)

Rolan Lobo — Sat, 30 May 2026 16:54:46 +0000

I'm going to be honest with you.

It started because I watched a spy movie, thought "this message will self-destruct in 5 seconds" was the coolest thing ever, and immediately opened VS Code instead of going to sleep like a normal person.

Seven days, one developer (me, just me, no team, no co-founder, no intern, nobody — just me, my laptop, and an unhealthy amount of coffee), I had Burn Chat running.

Here's what it does: you create a chat room with a countdown timer. Share the link. People join. You talk. When the timer hits zero, every single message on every single screen disappears. The server deletes everything. There's no history, no logs, no exports, no "deleted messages" folder. It's just... gone. Forever.

This is the story of how I built it, what I got completely wrong, and the parts I'm actually proud of.

👉 Try it live: bar-rnr.vercel.app/burn-chat

What I Was Actually Going For

The feature list I had in my head at 2am:

⏱️ Set a countdown timer (5 min to 24 hr)
🔐 End-to-end encryption — the server should never be able to read messages
🔥 When the timer hits zero, everyone sees a fire animation simultaneously
🔗 One link to share, no accounts, no sign-up
👑 A PIN so the creator can kick people, lock the room, extend the timer
🚫 Absolutely nothing stored on disk or in a database

That last one is important. If I'm going to call this "ephemeral", it had better actually be ephemeral. Not "ephemeral but we keep logs for 30 days for compliance reasons." Actually gone.

The Architecture (Or: What I Drew on a Napkin)

Your Browser                 My Server                  Their Browser
────────────────             ──────────────             ──────────────
Generate keys                                           Generate keys
Send public key  ──────────► store in RAM ────────────► get public key

Encrypt message  ──────────► relay blob   ────────────► decrypt message
(AES-GCM)        server sees ????base64????              (AES-GCM)
                 literally has no idea
                 what it says

The server is a blind courier. It sees base64 blobs going in one WebSocket and coming out another. It has no idea what the messages say. It stores nothing on disk.

This is not a marketing claim. The server genuinely cannot decrypt the messages because it never has the keys.

Part 1: The Backend — Python, FastAPI, and Some Questionable Choices

I Used a Dictionary to Store Sessions

# I could have used Redis. I used this.
_SESSIONS: Dict[str, _ChatSession] = {}

Yes. A plain Python dictionary. In memory. On one process.

You might be thinking: "that's not scalable."

You're right. It's also exactly what I needed. Here's my thinking:

If I store sessions in Redis, Redis is a database. Databases write to disk. If data touches disk, it can be recovered. I'm building a feature whose entire selling point is that data CANNOT be recovered. A plain in-memory dict that disappears when the process restarts is a feature, not a bug.

I'm one person. I have one dyno. It works. When I need to scale, I'll figure out sticky sessions + Redis with a EXPIRE key. That day is not today.

Each Session Gets a Timer

async def _countdown_loop(token: str, session: _ChatSession) -> None:
    try:
        while True:
            now = datetime.now(timezone.utc)
            remaining = (session.expires_at - now).total_seconds()

            if remaining <= 0:
                break

            # Coarse ticks when there's plenty of time.
            # 1-second ticks in the final minute for smooth UI animation.
            interval = 1.0 if remaining <= 60 else 10.0
            sleep_for = max(0.05, min(interval, remaining))
            await asyncio.sleep(sleep_for)

            # ⚠️ Always recompute from the wall clock.
            # Never trust sleep() duration — it drifts under load.
            remaining = (session.expires_at - datetime.now(timezone.utc)).total_seconds()

            await _broadcast(session, {
                "type": "countdown",
                "seconds_remaining": max(0, int(remaining))
            })

    except asyncio.CancelledError:
        return

    await _destroy_session(token)

The important bit: always recompute remaining from the actual wall clock. Never decrement a counter. Python's asyncio.sleep() can sleep longer than you asked if the event loop is busy. If you accumulate sleep durations, your 10-minute timer ends up being 11 minutes. Recomputing from expires_at - now every tick keeps it accurate.

Burning the Session

async def _destroy_session(token: str) -> None:
    session = _SESSIONS.get(token)
    if session is None:
        return  # already gone, nothing to do

    # Step 1: Tell EVERYONE to show the fire animation.
    await _broadcast(session, {"type": "destroyed"})

    # Step 2: Close every WebSocket connection.
    for participant in list(session.participants.values()):
        try:
            await participant.ws.close(code=1000, reason="Session expired")
        except Exception:
            pass

    # Step 3: Delete from memory. This IS the burn.
    _SESSIONS.pop(token, None)

Order is important here. Broadcast first — otherwise you'd close the connections before clients know to show the animation. Everyone sees the fire at the same time because the broadcast goes out in a single loop before any connections are closed.

Part 2: The Crypto — The Part That Made My Brain Hurt

I want to be upfront: cryptography is hard. I read a lot. I tested a lot. I still probably got some edge case wrong. But here's what I implemented and why.

Key Generation

Every person who joins generates an ECDH P-256 keypair in their own browser:

const keypair = await crypto.subtle.generateKey(
  { name: 'ECDH', namedCurve: 'P-256' },
  false,         // ← this means the private key CANNOT be exported
  ['deriveKey']
);

See that false? That's extractable: false. The Web Crypto API gives you a hard guarantee: even if some JavaScript on the page tries to export that private key, the browser will refuse. The private key is born in your browser and dies in your browser.

The Key Exchange

Each participant broadcasts their public key to the server. The server stores it (as an opaque blob it can't use for anything) and relays it to everyone else:

// You send this when you connect
ws.send(JSON.stringify({
  type: 'pubkey',
  public_key: await exportPublicKey(myKeypair)
}));

The creator then derives a shared ECDH secret with each participant, generates one AES-GCM-256 session key, and sends each person a version wrapped (encrypted) with their specific shared secret:

async function wrapSessionKey(sessionKey, peerPublicKeyB64, myPrivateKey) {
  // Derive a shared secret using our private key + their public key
  const sharedSecret = await crypto.subtle.deriveKey(
    { name: 'ECDH', public: await importPeerPublicKey(peerPublicKeyB64) },
    myPrivateKey,
    { name: 'AES-KW', length: 256 },
    false,
    ['wrapKey']
  );

  // Wrap the session key with the shared secret
  const wrapped = await crypto.subtle.wrapKey('raw', sessionKey, sharedSecret, 'AES-KW');
  return btoa(String.fromCharCode(...new Uint8Array(wrapped)));
}

The server receives an opaque blob for each recipient and delivers it. It has no idea what's inside. Even if someone hacked my server right now while you were chatting, they'd get base64 they can't do anything with.

Encrypting Messages

Every message gets a fresh 12-byte random IV:

async function encryptMessage(text, sessionKey) {
  const iv = crypto.getRandomValues(new Uint8Array(12));  // fresh every time
  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    sessionKey,
    new TextEncoder().encode(text)
  );

  return {
    ciphertext: btoa(String.fromCharCode(...new Uint8Array(ciphertext))),
    iv: btoa(String.fromCharCode(...iv)),
  };
}

Fresh IV per message is non-negotiable. I'll explain why in the mistakes section.

The Session Fingerprint

After key exchange, everyone computes this:

async function deriveFingerprint(sessionKey) {
  const raw = await crypto.subtle.exportKey('raw', sessionKey);
  const hash = await crypto.subtle.digest('SHA-256', raw);
  const bytes = new Uint8Array(hash);
  return Array.from(bytes.slice(0, 3))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');  // something like "a3f9c2"
}

Everyone in the session sees the same 6-character hex code. If you're paranoid, read it out loud to the other person. If your codes match, the key exchange wasn't tampered with. Is it perfect? No. Is it better than nothing? Absolutely.

Part 3: The Frontend — React, Fire, and a State Machine

Three Phases, One Component

The entire chat UI lives in one state variable:

const [phase, setPhase] = useState('join');
// 'join'      → name entry, waiting to connect
// 'chat'      → connected, messaging, countdown ticking
// 'destroyed' → fire animation, then... nothing

Simple. No routing. No URL changes. Just a state string that drives which thing you see.

The Burn Animation

The part I spent way too long on and absolutely do not regret:

// BurningAnimation.jsx
// mode="chat" for Burn Chat, mode="file" for file destruction

{mode === 'chat' ? (
  <div className="text-center">
    <Flame size={56} className="text-orange-400 animate-pulse mx-auto" />
    <h2 className="text-2xl font-bold text-orange-400 mt-4">
      Session Burned
    </h2>
    <p className="text-gray-400 text-sm mt-2">
      All messages have been permanently erased. No trace remains.
    </p>
  </div>
) : (
  <div className="text-center">
    <FileX size={56} className="text-red-400 mx-auto" />
    <h2 className="text-2xl font-bold text-red-400 mt-4">
      File Destroyed
    </h2>
  </div>
)}

I reused the same animation component for file destruction and chat destruction, added a mode prop, and now it knows which version to show. The timing, the progress bar, the fade — all identical. Different icon, different text, different feeling.

Creator Controls

When you create a session, you get a PIN. Enter it when you connect and you unlock: kick participants, lock the room so no one new can join, and extend the countdown. The PIN is sent over the WebSocket (under TLS) and compared server-side with secrets.compare_digest() — constant-time comparison so you can't do timing attacks to guess digits one by one.

Three wrong PINs in 10 minutes and you're locked out. I'm not taking any chances with brute force.

The Mistakes (a.k.a. The Educational Section)

Mistake 1: I Reused the IV

Early version. I generated one IV when the session was created and reused it for every message.

This is catastrophically wrong with AES-GCM.

Reusing an IV with the same key doesn't just "weaken" the encryption. It breaks it completely. An attacker who collects two messages encrypted with the same key and same IV can XOR the ciphertexts and recover the XOR of the plaintexts — which combined with any knowledge of one message's content, reveals the other. The 96-bit IV space with fresh random IVs per message means you'd need to send ~4 billion messages before a collision becomes likely. Fine.

Fresh IV every single time. No exceptions.

Mistake 2: I Forgot About Late Joiners

Alice creates the session. Bob joins. They exchange public keys. The session key is distributed.

Then Carol joins.

Carol never received Bob's public key broadcast. Bob's not going to re-send it — he already sent it. Carol can't decrypt anything Bob sent before she joined.

The fix: store every participant's public key on the server-side participant object. When anyone joins, the server includes every existing participant's public key in the joined response. Carol gets everyone's keys in one message the moment she connects, no matter when she joins.

@dataclass
class _Participant:
    ws: WebSocket
    ws_id: str
    name: str
    is_creator: bool = False
    public_key: Optional[str] = None  # ← stored here, sent to late joiners

Mistake 3: I Decremented the Timer Instead of Using the Wall Clock

First implementation:

# WRONG — don't do this
remaining = ttl_seconds
while remaining > 0:
    await asyncio.sleep(1)
    remaining -= 1  # ← this drifts

Under any real server load, asyncio.sleep(1) sleeps for 1.003 seconds, or 1.01 seconds, or however long the event loop was busy. Multiply that over 600 ticks for a 10-minute session and your timer is off by 6–10 seconds.

The fix is what I showed earlier — always compute remaining = expires_at - datetime.now(). The wall clock doesn't drift.

What Actually Happens When It Burns

Let's trace the exact moment a session ends:

_countdown_loop wakes up, computes remaining ≤ 0
Calls _destroy_session(token)
Server broadcasts {"type": "destroyed"} to every WebSocket simultaneously
Every browser receives the message in the same event loop iteration
Every client's React state changes to phase = 'destroyed'
Every screen shows the flame animation at the same moment
Server closes all WebSocket connections
_SESSIONS.pop(token) — Python garbage collects the dict entry

From step 3 to step 8, the real-world time is milliseconds. There's no race where one person sees the burn and another doesn't for a few seconds.

The Honest Security Section

I'm not going to pretend this is Signal. Here's what it actually does:

Protects you from:

✅ Someone hacking my server and reading messages (server only has ciphertext)
✅ Passive network interception (TLS + E2E encryption)
✅ Accidentally leaving a chat history lying around
✅ The "I sent that to the wrong person" anxiety (it's gone in 5 minutes anyway)

Does NOT protect you from:

❌ The other person screenshotting your messages (classic)
❌ Someone compromising your browser specifically
❌ A sufficiently motivated adversary with physical access to a device
❌ The session fingerprint requires you to actually compare codes out loud — if you skip that step, technically MITM is possible

Use this for: private conversations you genuinely want to disappear.

Don't use this for: evading law enforcement, anything actually illegal, evidence tampering.

If I Had More Time (And More Energy)

Things I'd add if I weren't one person doing this in my spare time:

Redis + sticky sessions — right now the in-memory dict means one server instance. Horizontal scaling would need Redis (but with careful thought about what goes in Redis vs. stays ephemeral).

A proper ratchet — the current design uses one session key for all messages. The Double Ratchet algorithm (what Signal uses) gives each message its own key derived from the previous one — compromise of one message doesn't reveal any others. Cool. Complex. Maybe v2.

Forward secrecy at the server layer — currently if somehow the session key leaked, all past messages in that session could be decrypted. A proper ratchet would fix this.

The fingerprint experience — right now it's a code you can optionally compare. It should be more prominent, maybe with a visual comparison like Signal's Safety Numbers.

Try It

Two tabs. Open them both.

Go to bar-rnr.vercel.app/burn-chat
Create a session with a 5-minute timer
Copy the link, open it in the second tab
Send some messages between the tabs
Wait for the timer, or just wait for the fire

Everything disappears. Both tabs. At the same time.

It's a small thing but it never gets old.

Source code: github.com/Mrtracker-new/BAR_RYY

Built by one person, alone, late at night, because spy movies are inspiring and sleep is overrated. If you find a bug, open an issue. If you find a security hole, please tell me before you do anything fun with it. 🔥

Your Backend Is Leaking Secrets (Mine Was Too)

Rolan Lobo — Fri, 17 Apr 2026 16:11:52 +0000

Ever had that feeling where your app works perfectly… but deep down you know it's kinda unsafe?

Yeah — that was me.

So I went all-in on fixing some serious backend security flaws in my project:
👉 BAR (Burn After Reading) — a secure file system with self-destruct capabilities.

And honestly? This round of fixes made the project feel 10x more production-ready.

Let me walk you through what I fixed — in a way that actually makes sense 👇

🚨 The Problem

The app was functional, but under the hood:

Sensitive error messages were leaking 😬
Debug print() statements were everywhere
Logging wasn’t structured
Some code paths were… let’s say “questionable choices”

Nothing was breaking — but from a security perspective?
It needed serious tightening.

🛠️ What I Fixed (The Real Stuff)

1. 💀 Killing Error Leaks (Big One)

Before:

detail=str(e)

Yeah… that means if something fails, users might see internal errors, stack traces, even SMTP failures.

After:

detail=security.OPAQUE_500_DETAIL

Now:

Users get a generic safe message
Real errors go to logs (where they belong)

👉 Result: No internal system info leaks to clients

2. 🧼 Cleaning Up a Dead Function Parameter

There was this:

sanitize_error_message(error: str)

But… the parameter wasn’t even used properly 🤦‍♂️

So I:

Removed the useless parameter
Exported a clean constant:

OPAQUE_500_DETAIL

👉 Cleaner code, less confusion, fewer mistakes.

3. 📧 Fixing OTP Email Leak

This one was sneaky.

If OTP sending failed, the API returned:

detail=error_msg

Which could expose:

SMTP issues
Email service internals

After fix:

logger.error(...)
detail=security.OPAQUE_500_DETAIL

👉 Now:

Users see nothing sensitive
Devs still get full logs

4. 🕵️ Tamper Detection Logging (Finally Useful)

Before:

print(f"🚨 tamper detected: {tamper_exc}")

After:

logger.warning("[SECURITY] Possible tamper detected …")

👉 Why this matters:

Works with logging systems
Can trigger alerts
Actually usable in production

5. ⚠️ Logger Setup Order Fix

Yeah… this was subtle.

Before:

router = APIRouter()
logger = get_logger()

After:

logger = get_logger()
router = APIRouter()

👉 Prevents weird initialization issues and keeps things clean.

6. 🧯 Removing All `print()` From Security Logic

This was a big cleanup.

Replaced things like:

print("Wrong password")
print("File destroyed")
print("Brute force attempt")

With:

logger.warning(...)
logger.info(...)

👉 Why this matters:

print() = invisible in production
logger = structured, searchable, monitorable

✅ Verification (No Guesswork)

I didn’t just “hope it works” — I verified everything:

✅ No sanitize_error_message() calls left
✅ No detail=str(e) anywhere
✅ No security-related print() calls
✅ OTP leaks completely removed
✅ All files compile cleanly
✅ Logging is consistent across modules

🧠 What I Learned

Honestly, this round of fixes taught me something important:

Secure code isn’t about big features — it’s about small decisions done right.

Things like:

Not exposing errors
Logging properly
Keeping APIs predictable

These are the details that separate:
👉 a “working app”
from
👉 a production-ready system

🚀 Final Thoughts

This wasn’t a flashy update.

No UI changes.
No new features.

But under the hood?

👉 It made the app way more solid, safer, and professional

🔗 Check Out the Project

If you’re curious or want to explore the code:

👉 https://github.com/Mrtracker-new/BAR_RYY

💬 If You’re Building Something…

Take this as a reminder:

Don’t trust raw error messages
Never leave print() in security logic
Logging is your best friend
Small fixes = big impact

🔐 AES-256 Finally Makes Sense (And It’s Way Simpler Than You Think)

Rolan Lobo — Wed, 01 Apr 2026 17:11:12 +0000

Let’s be honest…

We’ve all heard this everywhere:

“Your data is secured with AES-256 encryption”

Cool… but what does that even mean?

I used to just nod like:
“Yeah yeah… sounds secure 😌”

But recently, I actually understood it — and trust me, it’s not as scary as it sounds.

So let me explain it to you in the simplest (and fun) way possible 👇

🧠 First, What is Encryption?

Encryption is basically:

👉 Turning your readable data into gibberish so no one else can understand it.

Example:


Hello → X7#pL@9!

Only someone with the correct key can turn it back into "Hello".

🔑 So What is AES?

AES stands for:

Advanced Encryption Standard

It’s one of the most secure encryption methods used today.

Used in:

Banking systems 💳
WhatsApp messages 💬
Wi-Fi passwords 📶
Even governments 🏛️

Yeah… it’s that serious.

💪 What Does “256” Mean?

AES comes in 3 types:

AES-128
AES-192
AES-256

👉 The number = key size (in bits)

So AES-256 = 256-bit key

Which basically means:

🔐 There are 2^256 possible keys

That number is insanely huge.

Like… even if you had the fastest computer in the world,
it would take billions of years to brute-force it.

🎯 Imagine This (Simple Analogy)

Think of AES-256 like this:

You have:

A super strong locker
A 256-digit password
And inside it → your data

Now imagine someone trying to guess that password…

Yeah… not happening anytime soon 😂

⚙️ How AES-256 Actually Works (Simple Version)

Okay, no boring math — just the idea:

Step 1: Data is split into blocks

Your data is divided into chunks (16 bytes each)

Step 2: Multiple rounds of scrambling (14 rounds!)

Each round does things like:

Mixing data
Shuffling bits
Substituting values

Basically:
👉 It completely scrambles your data again and again

Step 3: Secret key is applied

A 256-bit key is used in every round

This is what makes it secure 🔥

Step 4: Final Output

You get encrypted data like:


k9@Lm#2!zPq8...

Completely unreadable.

🔓 How Decryption Works

To get the original data back:

👉 You MUST have the same key

Then the process runs in reverse

And boom 💥


k9@Lm#2!zPq8... → Hello

🚫 Why Hackers Can’t Easily Break AES-256

Because:

Too many possible keys (2^256 🤯)
Too many transformation rounds
No shortcut to guess the correct key

Even supercomputers struggle.

💡 Where You See AES-256 in Real Life

You’re already using it daily:

🔐 HTTPS websites (the lock icon in browser)
💬 Messaging apps
💾 File encryption tools
☁️ Cloud storage

🧑‍💻 Why I Learned This

While working on my project InvisioVault (a file-hiding tool),
I realized:

👉 Hiding data is cool

👉 But securing it is next level

That’s when I explored AES-256.

✨ Final Thoughts

AES-256 sounds complicated…

But in reality, it’s just:

🔐 A super powerful way to scramble data using a secret key

If you’re a developer,
understanding this gives you a huge edge.

🚀 If You Made It This Far…

You officially understand AES-256 better than most beginners 💯

If this helped you, drop a like ❤️ or share it!

👋 Let’s Connect

I’m a beginner dev building cool stuff and learning every day.

More blogs coming soon 🚀

🧨 The Bugs That Almost Broke Sortify (And How I Crushed Them)

Rolan Lobo — Sun, 15 Feb 2026 15:03:43 +0000

Let me tell you something.

Apps don’t usually break because of complex algorithms.

They break because of:

A 0-byte file.
A random binary blob pretending to be text.
A filename like report:final*version?.docx
Or an undo operation that travels back in time… badly.

Sortify ran into all of these.
So I did what every developer eventually has to do:

I went into defensive programming mode.

This is the story of how I hardened Sortify’s invalid input handling — and made it way more stable in the process.

Check it out on GitHub:
🔗 Sortify — automatic file organizer

🗂️ 1. The “Empty File” Problem

You’d think an empty file wouldn’t be dangerous.

It’s literally nothing.

But that’s the problem.

No content → extraction logic behaves weirdly → AI categorization becomes unreliable.

So now we explicitly detect 0-byte files before doing anything:

if file_size_bytes == 0:
    logging.warning(f"Empty file detected (0 bytes): {file_path}")

What happens now?

✅ Empty files are detected instantly
✅ Logged properly
✅ Categorized using filename only
✅ No crashes
✅ No silent weirdness

Instead of “why did this behave strangely?”
Now it’s “Ah, it’s empty. Makes sense.”

Predictable > Magical.

💣 2. Binary Files Pretending to Be Text

This one was sneaky.

Some files looked harmless.

But internally?

Binary junk.

And when text extraction libraries try to read binary data…

You get:

Exceptions
Garbage output
Or mysterious failures

So I built a binary detector.

🧠 How It Works

We check:

First 8KB of the file
Presence of null bytes (\x00)
Ratio of non-printable characters

If more than 30% of characters are non-printable, we treat it as binary.

Why 30%?

Because real text files don’t look like corrupted alien transmissions.

If file is binary:

logging.info("Binary file detected, skipping content extraction")

And we:

✅ Skip text extraction
✅ Fall back to filename-based categorization
✅ Log everything
✅ Avoid crashes completely

Even if the file extension lies.

Doesn’t matter if it’s .txt, .md, or .conf.

Binary is binary.

No more surprise explosions.

😩 3. Windows Filename Rage

Previously, if someone tried to rename a file using invalid Windows characters…

They got a boring, unhelpful error.

Now?

We explain exactly what Windows hates:

Windows does not allow these characters in filenames:
  \ (backslash)  / (forward slash)  : (colon)
  * (asterisk)   ? (question mark)  " (quote)
  < (less than)  > (greater than)  | (pipe)

Plus a clear:

Please remove these characters and try again.

Simple change.

Massive UX improvement.

No more guessing what went wrong.

🕰️ 4. The Undo Operation That Could Have Been Dangerous

Undo is supposed to feel magical.

But under the hood, it’s risky.

What if:

The moved file was deleted?
The original location now has a new file?
Something changed between operations?

Previously, this could cause crashes or accidental overwrites.

Now?

We check everything.

Before undoing:

✅ Does the moved file still exist?
✅ Is the original location free?

If not?

We stop and clearly explain why:

Cannot undo: Original location is already occupied.
A file already exists at: ...
Please manually verify and move the file if needed.

No corruption.
No overwriting.
No chaos.

This one was a critical-level fix.

📊 Before vs After

Before

Empty files behaved weirdly
Binary files could crash extraction
Error messages were vague
Undo could break in edge cases

After

Empty files detected and logged
Binary files safely skipped
Clear, human-readable error messages
Undo operations protected and safe

It feels like the app matured overnight.

💡 What This Really Is

This wasn’t a “new feature” release.

This was a stability hardening phase.

The kind of work users never see.

But they feel it.

Because the app stops:

Crashing randomly
Acting unpredictably
Failing silently

Instead, it behaves like a professional desktop application.

🚀 Final Thought

The difference between a prototype and a production-ready app?

Not fancy AI.
Not cool UI.

It’s this:

Handling weird, messy, real-world input gracefully.

Users will always find edge cases.

Your job is to make sure they don’t break everything when they do.

Sortify is now much harder to break.

And honestly?

That feels better than shipping a new feature. 💙

Fixing a Frozen UI & a Sneaky Scheduler Crash — A Tale of Threads, Signals, and Defensive Code 🧵🔥

Rolan Lobo — Tue, 03 Feb 2026 14:43:07 +0000

If your app looks alive but feels dead… congratulations 🎉

You’ve probably blocked the main thread.

This post is a walkthrough of two real bugs I fixed recently:

A UI freeze caused by blocking file I/O on the main thread
A nasty crash where a scheduler ran before it was initialized

Both bugs were invisible during “small tests” and brutally obvious in real usage.

Let’s break down what went wrong, how I fixed it, and what I learned.

🧊 Problem #1: The UI Freeze from Hell

Symptoms

Clicking Organize Files froze the entire UI
Large file sets (50+ files) caused 5+ seconds of silence
No progress bar movement
Users thought the app had crashed (fair assumption)

Root Cause

I was doing exactly what every GUI app should never do:

Running file operations directly on the main GUI thread

Here’s the original code 😬

# Preview mode - BLOCKING code
temp_file_ops = FileOperations(dest_dir, "Organized Files", dry_run=True)
temp_file_ops.start_operations()

# 🚨 This loop blocks the UI
for file_path in self.selected_files:
    category_path = temp_file_ops.categorize_file(file_path)
    temp_file_ops.move_file(file_path, category_path)

temp_file_ops.finalize_operations()

That innocent-looking for loop?
Yeah… that was freezing everything.

✅ The Fix: Move Work Off the Main Thread

Instead of doing file I/O directly, I refactored preview mode to use the same background threading system already working for real file moves.

New Approach (Non-Blocking)

# Preview mode - NON-BLOCKING code
self.preview_file_ops = FileOperations(dest_dir, "Organized Files", dry_run=True)

self.processing_thread = ProcessingThread(
    self.selected_files,
    self.preview_file_ops
)

self.processing_thread.progress.connect(self.update_progress)
self.processing_thread.finished.connect(
    lambda: self._on_preview_finished(dest_dir)
)
self.processing_thread.error.connect(self.on_processing_error)

self.processing_thread.start()

Why This Works

File processing runs in a background thread
UI stays responsive
Progress bar updates in real time
Errors are handled safely via signals

✨ Chef’s kiss.

🪄 Showing the Preview After the Work Is Done

Instead of showing the preview dialog immediately, I added a new handler that fires only after the background thread finishes:

def _on_preview_finished(self, dest_dir):
    self.progress_bar.setVisible(False)

    if self.preview_file_ops.dry_run_manager.has_operations():
        dialog = PreviewDialog(
            self.preview_file_ops.dry_run_manager,
            self
        )

        if dialog.exec() == QDialog.DialogCode.Accepted:
            self._execute_organization(dest_dir)
        else:
            self.status_bar.showMessage("Preview cancelled")

Result:

No frozen UI
No half-ready preview
Clean, predictable flow

📊 Before vs After (Quick Visual)

❌ Before (Blocking)

Main Thread
 └── Loop over files
     └── UI freezes 😵

✅ After (Non-Blocking)

Main Thread        Background Thread
 ├── UI alive 🟢    └── File processing
 ├── Progress bar  └── Categorization
 └── Signals       └── Dry-run tracking

🧨 Problem #2: The Scheduler That Crashed on Startup

This one was sneakier.

The Crash

Sometimes the app would crash when:

Auto-sort was enabled before manual organization
Scheduled jobs ran on fresh app start
The app reopened with existing schedules

The Culprit

The scheduler was created like this:

self.scheduler = SortScheduler(None, self.categorizer)

That None?
Yeah… file_ops wasn’t initialized yet.

So when the scheduler tried to move files:

💥 NoneType crash

🛡️ The Fix: Lazy Initialization + Defensive Guards

Step 1: Don’t Initialize Too Early

# Delay scheduler creation
self.scheduler = None

Step 2: Centralize Setup with `_ensure_file_ops()`

if self.scheduler is None:
    self.scheduler = SortScheduler(self.file_ops, self.categorizer)
    self.scheduler.start()
else:
    self.scheduler.file_ops = self.file_ops

Now:

Scheduler only exists when file_ops exists
No duplicated setup logic
No race conditions

🧯 Step 3: Defense in Depth (Crash Prevention)

Even with good initialization, I added guards inside the scheduler and watcher:

if self.file_ops is None:
    logging.error("FileOperations not initialized")
    return False

This ensures:

No crashes
Errors are logged
App degrades gracefully instead of exploding

🎯 Final Results

Before

❌ Frozen UI
❌ No progress feedback
❌ Random crashes
❌ Users panic

After

✅ Fully responsive UI
✅ Smooth progress updates
✅ Safe background execution
✅ Stable scheduler & watcher
✅ App feels professional

🧪 Testing Still Matters

I manually tested:

Small file sets
Large file sets
Preview ON / OFF
Auto-sort before manual use
Scheduled jobs on restart

Everything behaved exactly as expected 🎉

🧠 Takeaways

Never block the GUI thread
Reuse proven threading patterns
Lazy initialization beats eager crashes
Defensive checks save your future self
If the UI freezes, users will assume the worst

If you’re building desktop apps with Python + Qt:
Threads + signals are not optional — they’re survival tools.

Happy coding 🧑‍💻🔥
And may your UI never freeze again.

I Eliminated SQLite Race Conditions in a Multi-Threaded Python App 🚀

Rolan Lobo — Sun, 01 Feb 2026 14:59:13 +0000

Random crashes. Database corruption. “database is locked” errors.

That’s how my app Sortify behaved when multiple threads hit SQLite at the same time.

This post is how I fixed it properly — and made the database production-ready.

🧠 The Problem: SQLite + Threads = Trouble

SQLite is lightweight and fast — but it has a big footgun:

❌ A single database connection shared across threads is NOT safe

In my app Sortify, multiple components were running concurrently:

Auto-sort watcher
Manual file operations
Scheduler tasks
Background processing threads

All of them were touching the same SQLite connection.

Symptoms I Saw

Random crashes
database is locked errors
Inconsistent history data
Risk of database corruption
App instability during concurrent operations

This line was the silent killer 👇

sqlite3.connect(db_path, check_same_thread=False)

It disables safety, but does not make SQLite thread-safe.

💥 Why This Happens

SQLite allows multiple connections, but each connection must stay in one thread.

Sharing:

❌ cursors
❌ connections
❌ transactions

across threads causes race conditions.

✅ The Solution: Thread-Local Database Manager

I implemented a proper thread-safe architecture using:

threading.local()
Per-thread SQLite connections
Automatic retry logic
Centralized DB access layer

🧩 Introducing `DatabaseManager`

A brand-new module:

core/database_manager.py

Key Design Idea

Each thread gets its own SQLite connection

self._local = threading.local()

Connections are:

Created on demand
Stored per thread
Automatically reused inside that thread

🔐 Enforced Safety

sqlite3.connect(
    db_path,
    timeout=10.0,
    check_same_thread=True  # ✅ SAFE
)

If a thread tries to use another thread’s connection → SQLite blocks it immediately.

That’s what we want.

⚙️ Features of `DatabaseManager`

✔ Thread-Local Connection Pooling

Each thread has its own isolated connection

✔ Automatic Retry on Locks

Handles SQLite’s infamous:

OperationalError: database is locked

with retry + backoff logic.

✔ Transaction Support

execute_transaction(operations)

Ensures atomic writes even under load.

✔ Clean Shutdown

close_all_connections()

No leaked file handles. No corrupted DBs.

🔁 Fixing Existing Code

❌ Before: Shared Connection

self.conn = sqlite3.connect(db_path, check_same_thread=False)
self.cursor = self.conn.cursor()

✅ After: Thread-Safe Manager

from .database_manager import DatabaseManager
self.db_manager = DatabaseManager(self.db_path)

Every database call now goes through one safe gateway.

🧼 Removing Direct Cursor Access

❌ UI Code Touching DB Directly

cursor = self.history_manager.conn.cursor()
cursor.execute("DELETE FROM history")

✅ Proper Encapsulation

self.history_manager.clear_operations()
self.history_manager.clear_history()

No more hidden race conditions.

🧪 Stress Testing the Fix

I didn’t trust this blindly — I stress tested it hard.

Test Setup

5 threads
50 DB operations each
250 total concurrent writes

Results

Total operations: 250
Successful: 250
Failed: 0
Database records: 250

🎉 Zero failures. Zero locks. Zero corruption.

🧠 Thread-Local Connections Verified

✓ Number of unique connections: 3
✓ Each thread has its own connection

Exactly as designed.

📈 Impact

Before ❌

Random crashes
Locked database errors
Unsafe concurrent writes
App unstable under load

After ✅

Fully thread-safe database access
Stable concurrent operations
No corruption risk
Production-ready SQLite usage

🗂️ Files Changed

File	Description
`core/database_manager.py`	New thread-safe DB layer
`core/history.py`	Migrated all queries
`ui/main_window.py`	Removed direct DB access
`tests/test_database_threading.py`	Stress test suite

🚀 Lessons Learned

SQLite is thread-friendly, not thread-safe
check_same_thread=False is a trap
One connection per thread is the correct model
Centralizing DB access prevents future bugs
Stress tests reveal bugs unit tests won’t

🔗 Source Code

📦 GitHub Repository:
👉 https://github.com/Mrtracker-new/Sortify

🏁 Final Thoughts

This wasn’t just a bug fix — it was a foundational stability upgrade.

If your Python app:

Uses SQLite
Has background threads
Randomly crashes under load

👉 This pattern will save you.

Happy coding! 🚀

Introducing QR Code Steganography: Because Normal QR Codes Are Too Mainstream

Rolan Lobo — Sun, 25 Jan 2026 14:28:27 +0000

The Problem Nobody Knew They Had

You know what's boring? Regular QR codes. You scan them, they take you to a website. Yawn. 😴

You know what's exciting? QR codes that look totally normal to everyone else, but secretly contain hidden messages that only you can read. Spy level: 100. 🕵️‍♂️

So I built exactly that into InvisioVault. Because why should images have all the steganography fun?

What Makes This Different?

Most QR code generators can add text. Cool. But that text is in the QR data itself - anyone with a scanner can see it.

InvisioVault's QR codes are double agents. They have:

📱 Public data - What normal scanners see (your URL, contact info, whatever)
🔐 Hidden secret - Only visible when scanned with InvisioVault

Scan it with your phone? Goes to your website.

Scan it with InvisioVault? Reveals your secret message.

Same QR code. Two completely different experiences. Magic? No. URL fragments? Yes.

How It Works (The Nerdy Bits)

When you generate a QR code with InvisioVault, we encode it like this:

https://yourwebsite.com/#IVDATA:encrypted_secret_goes_here

Here's the clever part:

Normal QR scanners read the URL and open your browser
Browsers ignore everything after the # (it's a URL fragment)
Your website loads perfectly - no weird data, no errors
InvisioVault reads the full QR data including the fragment
We decrypt and display your hidden message 🎉

It's like hiding a secret note inside a birthday card, except the birthday card is a QR code and the note is encrypted with AES-256. As one does.

The Journey: A Tale of Trial and Error

Attempt 1: Null Byte Separation

"Let's use \x00 to separate public and private data!"

Result: Some scanners URL-encoded it. URLs looked like website.com%00garbage. Fail. ❌

Attempt 2: LSB Image Steganography

"Hide the secret in the QR code pixels!"

Result: Camera captures recompress images. Pixel data destroyed. Hidden message? Gone. Double fail. ❌❌

Attempt 3: URL Fragments

"What if we just... use URL fragments?"

Result: IT ACTUALLY WORKS. ✅

Sometimes the simple solution is the right solution. Sometimes you just need to fail twice first.

Live Camera Scanning 📷

But wait, there's more! You can now scan QR codes directly with your webcam. No screenshots, no uploads, just point and scan.

The technical magic:

5-tier progressive camera fallback (works on 95%+ devices)
Dual-canvas processing:
- Original canvas: Preserves color for extraction
- Enhanced canvas: 2x upscaling + grayscale + 50% contrast boost
Adaptive scan intervals (500ms → 2000ms with exponential backoff)
MD5-based request caching (60-80% cache hit rate)

Translation: It works fast, on almost any device, and doesn't murder your server. Success! 🎊

Show Me The Goods! 📸

Generating a QR Code

Here's what it looks like when you create a secret QR code:

Just a normal-looking QR code generator... or is it? 😏

Scanning & Extracting the Secret

And here's what happens when you scan it with InvisioVault:

Public data? Check. Hidden secret message? Double check. Mission accomplished! ✨

Why This Is Actually Useful

"Okay cool, but when would I actually use this?"

Glad you asked! Here are some totally-not-made-up scenarios:

Business Cards 📇
- Public: Your LinkedIn profile
- Secret: Your actual phone number (for select people who scan it right)
Event Tickets 🎫
- Public: Event website
- Secret: VIP access code or exclusive content link
Product Packaging 📦
- Public: Product information
- Secret: Warranty details or customer support portal
Marketing Materials 📰
- Public: Standard landing page
- Secret: Special discount code for InvisioVault users
Just Because You Can 🎉
- Public: Rick Roll link
- Secret: Actual content you wanted to share
- (Okay this one might be real)

Performance Stats 📊

Because numbers make everything more credible:

Metric	Result
QR Detection Rate	80%+ in good lighting
Device Compatibility	95%+
Backend Load Reduction	60-80% (thanks to caching)
Normal Scanner Compatibility	100% (they just ignore the secret)
Times I Thought This Wouldn't Work	47
Times I Was Wrong	1 (this time it worked!)

The Code Journey

This feature went through more iterations than I'd like to admit:

- Attempt 1: Data encoding with null bytes
+ Attempt 2: LSB pixel steganography
+ Attempt 3: URL fragment encoding ✓

Shoutout to:

Segno for QR generation
Pyzbar for QR scanning
URL fragments for existing and being perfect for this
Coffee for existing

Try It Yourself!

Head over to InvisioVault and give it a spin!

Generate a QR code with a hidden message
Scan it with your phone - see the public data
Scan it with InvisioVault - see the secret
Feel like a spy
Repeat until you've hidden secrets everywhere

What's Next?

Some ideas I'm considering (read: may or may not implement):

🎨 More QR customization options (logos, colors, patterns)
📊 Analytics to see who scanned your QR codes
🔗 QR code chaining (scan one, get led to another, treasure hunt style!)
🎭 Multiple hidden messages in one QR (because why not?)

Final Thoughts

Building this feature taught me several things:

The simple solution is often hidden behind two complicated ones
URL fragments are more useful than you think
Camera APIs are surprisingly well-supported now
LSB steganography is fragile and I should stop trying to make it work for everything

If you made it this far, congrats! You're either really interested in steganography, procrastinating on actual work, or both. Either way, thanks for reading! 🎉

Now go forth and hide secrets in QR codes. The world is your oyster. Or QR code. Same thing.

Technical Details (For the Curious)

If you want to dive deep into how this works:

Encryption:

AES-256-CBC with PBKDF2 key derivation
100,000 iterations (industry standard)
Random 16-byte salt and IV for each generation

QR Format:

{public_data}#IVDATA:{base64_encrypted_secret}

Camera Processing:

MediaStream API for webcam access
Canvas API for frame capture and enhancement
Dual-canvas approach for quality preservation
Real-time QR detection with adaptive intervals

Performance Optimizations:

MD5 hashing for request deduplication
In-memory caching with 1-second TTL
Exponential backoff to reduce unnecessary processing
Progressive camera configuration fallback

Made with 💜 by Rolan

P.S. - If you find any bugs, they're not bugs, they're undocumented features. But please tell me anyway. 😅

Share Your Creations!

If you create something cool with this feature, tag me! I'd love to see what creative uses people come up with for hidden QR messages.

GitHub: @Mrtracker-new

Email: rolanlobo901@gmail.com

Happy hiding! 🎭✨

Stop Making Your Users Play 'Will It Fit?'

Rolan Lobo — Fri, 23 Jan 2026 16:43:07 +0000

Stop Making Your Users Play 'Will It Fit?'

The Problem

My steganography app lets users hide files inside images. Cool, right? Except users kept getting this:

❌ Error: Image doesn't have enough capacity.

After uploading everything. After waiting. After clicking the button.

So they'd try a bigger image. Upload again. Click. Fail. Repeat until rage-quit.

Not great for retention. 📉

The Solution

I added a real-time capacity calculator that shows users if their file will fit before they click anything.

It's just a React component that:

Calculates capacity when files are selected
Shows a color-coded progress bar
Tells users upfront: "✅ File will fit comfortably" or "❌ Too big buddy"

The Code (The Interesting Bits)

Backend - Calculate how much fits in an image:

@api.route('/calculate-capacity', methods=['POST'])
def calculate_capacity():
    img = Image.open(image_path).convert("RGB")
    total_pixels = len(list(img.getdata()))

    # LSB stego: 3 bits per pixel / 8 = bytes
    capacity = (total_pixels * 3) // 8

    return jsonify({'totalCapacityBytes': capacity})

Frontend - Debounce so we don't spam the API:

useEffect(() => {
    // Wait 500ms after user stops typing
    const timeout = setTimeout(() => {
        calculateCapacity()
    }, 500)

    return () => clearTimeout(timeout)
}, [image, file, text, password])

The Pretty Part - Color-coded status:

const getStatus = (percentage) => {
    if (percentage > 100) return { icon: '❌', message: 'Too large!' }
    if (percentage > 90)  return { icon: '⚠️', message: 'Barely fits' }
    if (percentage > 70)  return { icon: '⚡', message: 'High capacity' }
    return { icon: '✅', message: 'Fits comfortably' }
}

The Plot Twist

I deployed it. Users loved it. Then:

❌ Failed to calculate capacity

Turns out my 50 req/hour rate limit couldn't handle users actually using the feature. Whoops.

Fix: Bumped to 100 req/hour + added debouncing = happy users.

The Results

Zero "file too large" complaints (down from many)
Users understand capacity limits without reading docs
App feels way more professional
I learned about debouncing the hard way

Key Takeaways

1. Show, don't tell - Real-time feedback > documentation

2. Debounce everything - Users type fast. Your API can't keep up. Plan accordingly.

3. Polish matters - That shine animation on the progress bar? Totally unnecessary. Users love it anyway.

4. Watch your rate limits - Good features get used. A lot. Be ready.

Try It Yourself

The full code is on GitHub. Feel free to steal, improve, or roast my implementation.

Sometimes the best features aren't the flashy new capabilities - they're the tiny UX tweaks that make users go "oh thank god, finally."

What small feature transformed your app's UX? Drop it in the comments! 👇

Building steganography tools at 3 AM with too much coffee ☕

Follow: @Mrtracker-new

Stop Lying to Your Users With Spinning Circles

Rolan Lobo — Thu, 22 Jan 2026 16:28:32 +0000

I Gave My Loading Screens a Glow-Up (And You Can Too!) 💅

You know that awkward moment when your app is loading and all your users see is a lonely spinning circle? Yeah, me too. So I decided to do something about it.

The Problem: Spinners Are Liars 🤥

Picture this: You're building a file encryption app (yes, that's what I do for fun), and your backend is sleeping on Render's free tier. When someone tries to access a file, they click the button and... nothing. Just a spinner. For 15 seconds.

No feedback. No progress. Just vibes. ✨

Users are left wondering:

Is it working?
Did I break it?
Should I refresh?
Is it time to panic yet?

Spoiler: They always panic.

The Solution: Multi-Stage Loading Indicators 🎯

Instead of a basic spinner that screams "I'm working, trust me bro," I built a loading component that actually communicates with users. Here's what it does:

🔵 Stage 1: Connecting

"Waking up server..." (because yes, it's literally waking up from a nap)

🟣 Stage 2: Authenticating

"Authenticating request..." (fancy words for checking if you're allowed in)

🟡 Stage 3: Decrypting

"Decrypting file..." (the actual magic happens here)

🟢 Stage 4: Rendering

"Rendering preview..." (almost there!)

Each stage gets its own:

Icon (Server → Shield → Lock → Eye)
Color (Blue → Purple → Amber → Green)
Progress percentage (0% → 25% → 50% → 75% → 100%)
Smooth animations (because we're fancy like that)

The Code: Let's Get Spicy 🌶️

I created a reusable LoadingStages component that takes the current stage and progress as props:

<LoadingStages
  currentStage="connecting"
  progress={25}
  estimatedTime={15}
/>

The component cycles through stages automatically based on your app's actual loading process. No fake progress bars here! (We're honest people.)

Cold Start Detection 🥶

The best part? It detects when the server is cold-starting and shows an estimated time:

const responseTime = (Date.now() - startTime) / 1000;
if (responseTime > 3) {
  setEstimatedTime(15); // "~15s" appears on screen
}

This way, users know they're in for a wait and can grab their coffee ☕

The Results: Happy Users 😊

Instead of anxious button-mashing, users now:

See exactly what's happening at each stage
Know how long it'll take during cold starts
Feel confident the app is working
Don't spam refresh (my server thanks them)

Plus, it looks gorgeous. The glassmorphic design with color transitions makes loading actually pleasant to watch.

Want to Try It? 🚀

Check out the full implementation in my repo:
BAR_RYY

The magic lives in:

frontend/src/components/LoadingStages.jsx (the star of the show)
frontend/src/components/SharePage.jsx (where it's integrated)

Key Takeaways 💡

Loading screens are prime real estate - Use them to communicate!
Users tolerate waits better when they know what's happening
Cold start detection turns frustration into understanding
Pretty animations make everything better (scientific fact)

Final Thoughts 🎨

We spend so much time optimizing for speed, but sometimes the wait is unavoidable (looking at me, free tier cold starts). When you can't eliminate the wait, make it informative and beautiful.

Your users will appreciate knowing that yes, the app is working, and no, they don't need to panic.

Now if you'll excuse me, I'm off to give all my loading screens glow-ups. This is addicting. 💅✨

What's the most creative loading indicator you've seen? Drop it in the comments! 👇

P.S. - If you're building anything with file encryption, 2FA, or self-destructing links, definitely check out the repo. It's got some cool security features too!

How I Stopped Worrying and Learned to Love Organization

Rolan Lobo — Wed, 21 Jan 2026 15:57:03 +0000

The Before Times (aka The Dark Ages)

Picture this: You open your backend folder. It's like walking into a teenager's room. Files everywhere. No rhyme. No reason. Just pure, unadulterated chaos.

database.py living next to upload.py, hanging out with security.py, while cleanup.py just vibes in the corner. Everyone's at the same level, nobody has their own space, and finding anything requires either:

A prayer 🙏
Ctrl+P like your life depends on it
Or acceptance that you'll spend 10 minutes scrolling

Sound familiar? Yeah, I thought so.

The Intervention

One day, I looked at my backend folder and had an epiphany. Or maybe it was just caffeine-induced clarity. Either way, I realized something profound:

My files were adults. They deserved their own rooms.

So I did what any responsible developer would do: I created folders. ACTUAL. FOLDERS.

backend/
├── core/           # The VIPs
├── services/       # The workers
├── storage/        # The file hoarders
└── utils/          # The helpful folks

Revolutionary? No. Overdue? Absolutely.

The Great Migration (aka Moving Day)

Moving files is like playing Tetris, but with imports. You move one file and suddenly 47 things break. It's beautiful.

Step 1: Create folders

✅ Easy mode

Step 2: Move files into folders

✅ Still easy

Step 3: Update all the imports

⚠️ BOSS BATTLE INITIATED

# Before
from database import Database

# After
from core.database import Database

# My brain
from please.work.i.beg.you import Sanity

I spent quality time with find-and-replace. We bonded. We grew together. I may have shed a tear when all the imports finally worked.

What Actually Changed

Here's what I inflicted upon my codebase:

🎯 core/ - The Foundation

database.py - Because databases are core, obviously
config.py - All the environment variables in one place
auth.py - Security matters, folks

⚙️ services/ - The Doers

upload_service.py - Handles uploads
share_service.py - Handles sharing
cleanup_service.py - Cleans up after everyone else (the real MVP)

💾 storage/ - The Packrats

file_manager.py - Manages files (shocking, I know)
storage_handler.py - Stores things

🛠️ utils/ - The Helpers

security.py - Security utilities
validators.py - Validates stuff
helpers.py - Helps with... stuff

The Fallout

The Good:

Finding files is now actually possible
New team members don't look at me with fear and confusion
I can pretend I know what I'm doing
Separation of concerns is no longer just a buzzword I throw around

The Bad:

My muscle memory is completely wrecked
I still type old import paths
Had to update the mental map in my brain

The Ugly:

That one time I forgot to update an import and the server crashed in production
Just kidding! (Or am I? 😅)

Lessons Learned

Start with folders. Don't be like me. Don't wait until you have 30 files in the root directory.
Your IDE's refactoring tools are your friends. Use them. Love them. They'll save you from import hell.
Test after moving EVERYTHING. I mean it. Test it all. Then test it again.
It's never too late to organize. Even if your codebase is a disaster, you can fix it. I believe in you.
Document the structure. Future you will thank present you. Past you is already disappointed, but that's okay.

The Commit Message That Started It All

refactor: finally convinced my files to use folders like adults

- Created proper folder structure (core, services, storage, utils)
- Moved files from root to appropriate directories
- Updated all import statements
- Celebrated with coffee

Final Thoughts

Is my backend perfect now? No.

Is it better? Absolutely.

Did I learn something? Maybe.

Will I do this again? Already planning the frontend refactor.

Remember folks: Organization is not about being perfect. It's about being less chaotic than you were yesterday.

And if you're sitting there with a messy backend folder, take this as your sign. Your files deserve their own rooms too.

Now go forth and mkdir! 🚀

Have you ever done a massive refactor? Share your horror stories in the comments! I promise mine was worse. Probably.

Why Let Users Choose Between Being Nice and Being Paranoid? 🔄

Rolan Lobo — Tue, 20 Jan 2026 18:17:41 +0000

The Problem: My App Had Commitment Issues 💔

So I built this file-sharing web-app called BAR Web that lets you send files that self-destruct after being viewed (think Mission Impossible but for PDFs). Cool, right?

But here's where things got weird: I added two features to control how page refreshes work:

View Refresh Threshold - "Hey, if the same person refreshes within 5 minutes, don't count it as a new view"
Auto-Refresh Interval - "Force the page to reload every 30 seconds so the file disappears"

And like a fool, I let users enable both at the same time. 🤦‍♂️

What Could Go Wrong?

Imagine this conversation:

User: "I want to be nice! Let people refresh without wasting views!"

Also User: "But also force them to reload every 30 seconds!"

Me: "...that's like wearing a belt AND suspenders, my friend."

It made zero sense. If you're auto-reloading the page, why care about refresh thresholds? If you're being forgiving with refreshes, why force reloads?

It was like trying to be both chill and paranoid at the same time. Pick a lane, buddy!

The Solution: Couples Therapy for UI Elements 💑

I made them mutually exclusive using radio buttons. Now users have to choose ONE:

Option 1: View Refresh Threshold (The Nice One)

"I trust you not to spam refresh. Take your time!"

Perfect for:

Recipients who might have slow internet 📶
People who need to scroll through long documents
When you're feeling generous

Options:

0 minutes (every refresh counts - default)
5 minutes (recommended)
Up to 1 hour (very forgiving)

Example:

User refreshes 3 times in 4 minutes → Still counts as 1 view 🎯

Option 2: Auto-Refresh Interval (The Paranoid One)

"You have 30 seconds. Make them count. ⏱️"

Perfect for:

Super sensitive stuff
Time-limited access codes
Maximum security theater

Options:

10 seconds (ruthless)
30 seconds (recommended)
Up to 5 minutes (generous for paranoia mode)

Example:

User opens file → Has 30 seconds to read → Page reloads → File might be gone 💨

The Implementation (For the Nerds) 🤓

Frontend Magic

I used radio buttons styled like cards (same pattern as my storage mode selector):

// When "View Refresh Threshold" is selected
onChange={() => onRulesChange({
  ...rules,
  viewRefreshMinutes: 5,        // Enable this one
  autoRefreshSeconds: 0          // Disable the other
})}

// When "Auto-Refresh Interval" is selected  
onChange={() => onRulesChange({
  ...rules,
  viewRefreshMinutes: 0,         // Disable this one
  autoRefreshSeconds: 30         // Enable the other
})}

Then I show the dropdown settings only for the selected option. One choice, one settings panel. Clean and simple.

Backend Wisdom

The backend was already handling both features separately. I just had to make sure only one value is non-zero at a time:

# In the database
view_refresh_minutes: int = 0
auto_refresh_seconds: int = 0

# Only one should be > 0

The fingerprinting logic checks if enough time has passed, and the auto-refresh header tells the browser when to reload. Easy peasy.

Lessons Learned 🎓

Don't give users contradictory choices - It's our job to prevent foot-shooting
UI should reflect reality - If two options fight each other, make them exclusive
Good UX is about constraints - Sometimes the best feature is the one you don't include
Radio buttons > Checkboxes for mutually exclusive stuff (duh)

The Result 🎉

Now my app has a clear UI that says:

"Pick your personality: Nice or Paranoid. You can't be both, Karen."

Users love it. No more confusion. No more contradictory settings. Just clean, simple choices.

Try It Yourself!

The feature is live at bar-rnr.vercel.app

And if you want to see the code or contribute:

👉 GitHub: BAR_RYY

Fun fact: I committed this in 4 separate commits with increasingly silly commit messages. Because if you're not having fun while coding, what's the point? 😄

The last commit was literally:

"Docs got the memo! 📝 README and FEATURES.md now explain the new Smart Refresh Control with examples, emojis, and a healthy reminder that you can't enable both options because that'd be like wearing a belt AND suspenders 👖"

Have you ever built conflicting features into your app? Share your "oops" moments in the comments! 👇

How I Accidentally Became a Performance Guru

Rolan Lobo — Sun, 18 Jan 2026 15:51:58 +0000

The Classic Beginner Move: Doing Everything Backwards

You know that feeling when you're building your portfolio as a beginner and you suddenly think:

“THIS is going to be legendary.”

Yeah. That was me.

I planned everything with extreme seriousness:

✅ Cool animations
✅ Smooth transitions
✅ Project showcase
✅ Fancy tech stack badges
✅ Blog section
❌ Resume… eventually?

Here’s the thing about being a beginner:

You overthink the simple stuff

and underthink the important stuff.

I spent days perfecting my hero section animation.

But adding my actual resume to my portfolio?

“Eh… I’ll do it later.”

So naturally, I added my resume dead last.

You know —

the ONE thing employers might actually want to see.

By the time I got to it, I had already:

implemented three color themes
refactored my components twice
memorized half of the React docs
emotionally bonded with my CSS

Classic beginner behavior. 🤦‍♂️

The React-PDF Rabbit Hole 🕳️🐇

When I finally decided to add my resume, I told myself:

“I’m a developer now.

I must do this the developer way.”

So I did what any self-respecting beginner does:

🔍 Googled: “How to add PDF to React website”

And there it was.

✨ react-pdf ✨

A whole library just for PDFs?

Perfect.

Libraries = Professional.

More code = Smarter developer.

Right?

import { Document, Page } from 'react-pdf';

// Look at me using a library 😎
<Document file="/Rolan_Resume.pdf">
  <Page pageNumber={1} />
</Document>

I felt unstoppable.

Installed dependencies
Configured webpack
read 15 Stack Overflow answers
Fought canvas rendering errors
Questioned my life choices

This was REAL development, right?

The Wake-Up Call 😱

Then I ran Lighthouse.

Performance: 67

💀💀💀

My beautifully crafted portfolio — the one I spent weeks polishing — was being absolutely murdered by a PDF renderer.

Mobile users were probably aging in real time
Resume loading slower than my motivation on Mondays
And for WHAT?

The PDF:

wasn’t interactive
didn’t zoom properly
took forever to load

I had officially used a sledgehammer to hang a photo frame.

The “Duh” Moment: WebP to the Rescue 🧠✨

One day, while optimizing my project images (you know… the things I optimized before my resume 🙃), I converted everything to WebP.

File sizes dropped like my hopes during a failed npm install.

And suddenly…

💡 It hit me.

“Wait…
Why am I rendering a PDF…
when I could just show an image?”

🤯🤯🤯

Groundbreaking thinking, I know.
Someone call the Nobel committee.

So I did the most un-developer thing possible:

Opened my resume PDF
Exported it as a high-quality image
Converted it to WebP
Deleted react-pdf like it owed me money

Replaced all of this complexity with:

<img 
  src="/resume-preview.webp" 
  alt="Resume Preview"
  loading="lazy"
/>

That’s it.

No library.
No config.
No pain.
Just ✨ a native <img> tag no libraries involved ✨.

The Results Were… Embarrassingly Good 😐

Before (react-pdf)

📦 Bundle size: +500KB
⏱️ Load time (3G): 3.2s
🎨 Lighthouse score: 67
😤 Stress level: High

After (WebP)

📦 File size: ~45KB
⏱️ Load time (3G): 0.3s
🎨 Lighthouse score: 95
😎 Stress level: Chill

I accidentally made my site 10x faster by doing the simplest thing possible.

What This Taught Me (Besides Humility)

1️⃣ Not Everything Needs a Library

Just because a library exists doesn’t mean you need it.

Sometimes the browser already does the job perfectly fine.

Using a library for this felt like buying a smart electric can opener…
when you have hands.

2️⃣ WebP Is a Game Changer

If you’re not using WebP yet… why? 😭

25–35% smaller than PNG/JPEG
Better quality at lower sizes
Supported by all modern browsers (sorry IE11, this party isn’t for you)

WebP is basically a free performance upgrade.

3️⃣ The Beginner Advantage 🧠

As a beginner, I wasn’t emotionally attached to “the right way”.

When something didn’t work well, I didn’t defend it.

I just went:

“This sucks.”
Delete.
Try something simpler.

That mindset saved my performance.

4️⃣ Performance > Complexity

No recruiter will ever say:

“Wow… you used react-pdf.”

But they will notice when your site loads faster than their coffee machine.

Users don’t see your code.
They feel your performance.

The Irony of It All 🎭

I thought being a “real developer” meant:

more libraries
more configs
more complexity

But the biggest improvement to my portfolio came from:

Converting a file
and using an <img> tag.

Sometimes the best code
is the code you don’t write.

How You Can Do This Too (Dead Simple)

Export your resume as a high-quality image
Convert it to WebP
Use this:

<img src="resume-preview.webp" alt="Resume" loading="lazy" />

Still offer the PDF download:

<a href="/resume.pdf" download>Download PDF</a>

Done. 🎉

You’ve now avoided:

PDF.js headaches
Webpack nightmares
“canvas is not defined” errors
Performance crimes

Final Thoughts

Building a portfolio as a beginner is basically:

doing things backwards
learning the hard way
accidentally discovering best practices

I added my resume last.
I over-engineered a simple problem.
But I learned something valuable:

Simple beats fancy.
Fast beats clever.
Users beat libraries.

If my Lighthouse score went from 67 → 95 just by using WebP…

Imagine what yours could be.

Now if you’ll excuse me, I need to refactor something that’s working perfectly fine —
you know, as developers do. 😅

TL;DR
Tried to be fancy with react-pdf, murdered performance.
Switched to WebP image preview, became accidentally fast.
WebP is magic. Simple is better.

Got similar over-engineering stories?
Drop them in the comments — let’s laugh at our beginner mistakes together 👇

P.S. Yes, my resume is still downloadable as a PDF.
I’m not a monster. But the preview?
That’s pure WebP goodness. 😌

DEV Community: Rolan Lobo

I Built a Chat App That Deletes Itself (Because I Was Bored at 2am)

What I Was Actually Going For

The Architecture (Or: What I Drew on a Napkin)

Part 1: The Backend — Python, FastAPI, and Some Questionable Choices

I Used a Dictionary to Store Sessions

Each Session Gets a Timer

Burning the Session

Part 2: The Crypto — The Part That Made My Brain Hurt

Key Generation

The Key Exchange

Encrypting Messages

The Session Fingerprint

Part 3: The Frontend — React, Fire, and a State Machine

Three Phases, One Component

The Burn Animation

Creator Controls

The Mistakes (a.k.a. The Educational Section)

Mistake 1: I Reused the IV

Mistake 2: I Forgot About Late Joiners

Mistake 3: I Decremented the Timer Instead of Using the Wall Clock

What Actually Happens When It Burns

The Honest Security Section

If I Had More Time (And More Energy)

Try It

Your Backend Is Leaking Secrets (Mine Was Too)

🚨 The Problem

🛠️ What I Fixed (The Real Stuff)

1. 💀 Killing Error Leaks (Big One)

2. 🧼 Cleaning Up a Dead Function Parameter

3. 📧 Fixing OTP Email Leak

4. 🕵️ Tamper Detection Logging (Finally Useful)

5. ⚠️ Logger Setup Order Fix

6. 🧯 Removing All print() From Security Logic

✅ Verification (No Guesswork)

🧠 What I Learned

🚀 Final Thoughts

🔗 Check Out the Project

💬 If You’re Building Something…

🔐 AES-256 Finally Makes Sense (And It’s Way Simpler Than You Think)

🧠 First, What is Encryption?

🔑 So What is AES?

💪 What Does “256” Mean?

🎯 Imagine This (Simple Analogy)

⚙️ How AES-256 Actually Works (Simple Version)

Step 1: Data is split into blocks

Step 2: Multiple rounds of scrambling (14 rounds!)

Step 3: Secret key is applied

Step 4: Final Output

🔓 How Decryption Works

🚫 Why Hackers Can’t Easily Break AES-256

💡 Where You See AES-256 in Real Life

🧑‍💻 Why I Learned This

✨ Final Thoughts

🚀 If You Made It This Far…

👋 Let’s Connect

🧨 The Bugs That Almost Broke Sortify (And How I Crushed Them)

🗂️ 1. The “Empty File” Problem

What happens now?

💣 2. Binary Files Pretending to Be Text

🧠 How It Works

If file is binary:

😩 3. Windows Filename Rage

🕰️ 4. The Undo Operation That Could Have Been Dangerous

📊 Before vs After

Before

After

💡 What This Really Is

🚀 Final Thought

Fixing a Frozen UI & a Sneaky Scheduler Crash — A Tale of Threads, Signals, and Defensive Code 🧵🔥

🧊 Problem #1: The UI Freeze from Hell

Symptoms

Root Cause

✅ The Fix: Move Work Off the Main Thread

New Approach (Non-Blocking)

Why This Works

🪄 Showing the Preview After the Work Is Done

📊 Before vs After (Quick Visual)

❌ Before (Blocking)

✅ After (Non-Blocking)

6. 🧯 Removing All `print()` From Security Logic

Step 2: Centralize Setup with `_ensure_file_ops()`

🧩 Introducing `DatabaseManager`

⚙️ Features of `DatabaseManager`