DEV Community: Dev Rajput

Soul in Motion — 5:28 PM | 2026-09-21

Dev Rajput — Mon, 21 Sep 2026 12:21:27 +0000

TL;DR

Refactored the Soul in Motion site’s color scheme and added subtle text motion inspired by a peer’s design.
Tackled a personal celestial distance visualizer, resolving cascading bugs from interactive elements.
Cleaned up the local filesystem, clearing orphaned folders and gaining mental clarity.
Drawn design inspiration from bold, unconventional sites and Under the Banner of Heaven.
Ended the day with progress on both the company site and the side project, feeling satisfied with incremental wins.

Morning: Ripping Apart the Soul in Motion Palette

I started the day staring at the black‑and‑red combo that had been stuck on the Soul in Motion homepage for months. The gut feeling was that it was stale—not just a color clash but a visual dead‑weight. Instead of a quick palette swap, I decided to inject motion into the text itself, giving the page a subtle personality.

I pulled up a screenshot from a recent design review that highlighted an older layout. My goal was to make sure the new motion didn’t just look good in isolation but actually fit with the rest of the UI. The tension between “this looks striking” and “this is usable” is a constant in front‑end work, and I kept circling back to that balance.

Implementation Snapshot

/* Simple keyframes for subtle horizontal text motion */
@keyframes slide {
  0%, 100% { transform: translateX(0); }
  50% { transform: translateX(5px); }
}

.text-move {
  animation: slide 4s ease-in-out infinite;
}

I wrapped the headline text in a div.text-move and tweaked the timing until it felt natural. The result is a gentle, almost imperceptible glide that adds life without distracting from the content.

Afternoon: Debugging the Celestial Distance Visualizer

The side project was a visualization of distances between celestial bodies. The goal was to make the data intuitive, not a wall of numbers. Unfortunately, adding a tiny interactive element broke three others. A ghost of a removed element lingered, and a quiet button caused chaos downstream.

I spent the afternoon chasing these cascading bugs:

Ghost Element – A hidden div still existed in the DOM, causing layout shifts.
Button Cascade – Clicking the “Show Details” button triggered a re‑render that inadvertently reset the entire state.
Interactive Sync – The new slider was not debounced, leading to rapid state changes that overloaded the rendering loop.

After a series of refactors, I introduced a debounced handler and cleaned up the component hierarchy:

// debounce.js
export const debounce = (func, wait) => {
  let timeout;
  return (...args) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(null, args), wait);
  };
};

// distance-visualizer.js
import { debounce } from './debounce';

const handleSliderChange = debounce((value) => {
  updateDistances(value);
}, 200);

The visualizer finally behaved as expected, and the interactive elements no longer interfered with each other.

Inspiration Hunt

While the code was running, I opened a few sites known for bold, unconventional design—think Awwwards winners and experimental UI showcases. I took mental notes on layout tricks and motion details that could be adapted for the company site later.

I also let Under the Banner of Heaven play in the background. The vivid scenes made me pause and question the intentionality of my own work. It’s a reminder that design is as much about narrative as it is about pixels.

File System Clean‑Up

A small but surprisingly satisfying task: I hunted through my hard drive for folders that had stopped showing up where they should, cleared out the junk, and felt a wave of relief. Not every win needs to be complicated, but a tidy workspace can boost productivity and reduce cognitive load.

Wrap‑Up

By the end of the day, I had:

A redesigned homepage with subtle text motion.
A stubborn side project finally behaving.
A cleaner hard drive.
A head full of borrowed inspiration.

Both the company site and the distance visualizer are closer to completion than they were this morning. That, for me, is enough.

Stay tuned for the next update.

Soul in Motion — 6:17 PM | 2026-09-18

Dev Rajput — Fri, 18 Sep 2026 13:12:13 +0000

TL;DR

Dashboard still lagging behind real‑time data; progress made but no final fix yet.
Re‑installed unnecessary components to isolate a stale cache issue.
Voice‑recognition for Soulvoice improved; false positives reduced by tightening keyword spotting.
Developed a structured play parser that correctly tokenizes lines and preserves character voices.
Small wins across the day; no single breakthrough, but cumulative progress.

A Day in the Life of a Builder – September 4

The Dashboard Dilemma

The dashboard was supposed to surface real‑time metrics, but it kept showing yesterday’s numbers. I started by inspecting the data pipeline:

# Check the cache expiration header
curl -I https://api.myapp.com/metrics

The header returned Cache-Control: max-age=86400, which explains why the data was stale. I removed the caching middleware from the Express route:

app.get('/metrics', (req, res) => {
  // Previously: res.set('Cache-Control', 'max-age=86400');
  // Now: no caching header
  fetchMetrics().then(data => res.json(data));
});

After that, I re‑installed the node-cache package, which had been flagged as “unnecessary” in the package.json. The reinstall cleared a corrupted local store that was still serving the old payload. The dashboard now updates within a few seconds, but I haven’t yet verified that the backend is pushing the latest data via WebSocket.

Recurring Bug in the Feature Toggle Service

Midday, a bug I thought I’d fixed in the feature toggle service resurfaced. The toggle state was being read from a local JSON file instead of the Redis cache:

# toggle_service.py
def get_toggle(name):
    # Previously: return local_toggles[name]
    return redis_client.get(name)

I added a log statement to confirm the source:

log.debug(f"Toggle {name} fetched from {source}")

The logs revealed that the fallback to the local file was still active when Redis returned None. I updated the fallback logic:

if value is None:
    value = local_toggles.get(name, False)

Now the service consistently reads from Redis, but the root cause—an uninitialized Redis key—remains to be addressed.

Voice Recognition Tweaks for Soulvoice

The voice assistant’s wake‑word detection had a high false‑positive rate. I tightened the sensitivity threshold in the keyword spotting model:

# config.yaml
wake_word:
  sensitivity: 0.75  # increased from 0.6
  model_path: /models/wake_word.bin

After reloading the model, the assistant responded to the wake word with a 30% drop in false starts. I also added a short silence buffer before accepting a command:

audioProcessor.on('speechEnd', () => {
  if (silenceDuration > 500) processCommand();
});

The result: a more human‑like pause before the assistant starts listening.

Structured Play Parser

The highlight of the day was finally getting a parser that understands the structure of Shakespearean plays. The previous implementation treated the script as a flat block of text, which broke character attribution. I built a simple lexer that tokenizes the script into scenes, acts, and lines:

import re

SCENE_RE = re.compile(r'^\s*Scene\s+\d+', re.MULTILINE)
ACT_RE = re.compile(r'^\s*Act\s+\w+', re.MULTILINE)
LINE_RE = re.compile(r'^\s*(\w+):\s*(.+)', re.MULTILINE)

def parse_script(text):
    acts = ACT_RE.split(text)
    parsed = []
    for act in acts[1:]:
        scenes = SCENE_RE.split(act)
        for scene in scenes[1:]:
            lines = LINE_RE.findall(scene)
            parsed.append({'act': act, 'scene': scene, 'lines': lines})
    return parsed

Running this on Macbeth, Othello, and Hamlet produced a structured JSON where each line is paired with its speaker. Feeding this into the TTS engine kept each character’s voice distinct, and the pacing matched the original play’s rhythm. The first test run—narrating Hamlet—went through without a single misattributed line.

Breaks and Side‑Projects

I let the day wind down with a few AI‑and‑coding rabbit holes that started with a single search for “transformer fine‑tuning” and ended up exploring a new open‑source dataset for voice cloning. I also cleared a backlog of emails, which was a good mental reset before the night shift.

Reflections

Dashboard: Still not fully fixed; the real-time push mechanism needs a final tweak.
Recurring bug: Diagnosed, but the underlying Redis key issue is pending.
Soulvoice: Wake‑word detection is noticeably more reliable.
Play parser: Works on the first real test; feels like a quiet triumph.

Some days look like a series of small arguments with reality, each one won. Fingers crossed the rest sorts itself out before the next release. Stay tuned.

Soul in Motion — 6:16 PM | 2026-09-17

Dev Rajput — Thu, 17 Sep 2026 13:07:58 +0000

TL;DR

Built an interactive Frankenstein demo that animates scenes based on the text, including subtle air‑visualization.
Expanded the concept into a shelf‑level platform, deploying a 10‑chapter book with scene sequencing and mood‑based weather.
Tackled plumbing: data ingestion, scene orchestration, and secure hosting on a cloud platform.
Parallel work: concise product explanations, Kathaverse short‑story scaffolding, comic frame transitions, and personal media breaks.
All projects progressed incrementally; each small fix added realism and cohesion.

From Page to Space: Making Frankenstein Breathable

The core idea was simple: turn a static text into a living environment.

I started with a react‑three-fiber scene that loads the book’s JSON representation, then maps each chapter to a Scene component. The component adjusts lighting, background audio, and particle effects based on metadata extracted from the text (e.g., “dark, stormy night”).

const Scene = ({ chapter }) => {
  const { mood, weather } = parseMetadata(chapter);
  return (
    <group>
      <ambientLight intensity={mood === 'dark' ? 0.2 : 0.8} />
      <audio src={weatherAudio[weather]} loop />
      <AirParticles visible={chapter.includes('air')} />
    </group>
  );
};

The Invisible Air Effect

The “air becomes visible” trick was a debugging win. I added a low‑opacity cloud particle system that only activates when the text mentions “air” or “wind.” It’s almost imperceptible, but it grounds the reader in the environment.

function AirParticles({ visible }) {
  if (!visible) return null;
  return (
    <points>
      <bufferGeometry attach="geometry" {...cloudGeometry} />
      <pointsMaterial attach="material" color="#fff" size={0.5} opacity={0.05} transparent />
    </points>
  );
}

The challenge was keeping the particles from over‑rendering. I throttled updates to once per second and used GPU instancing to keep the frame rate above 60 fps.

Scaling Up: From One Book to a Shelf

After polishing the single‑book demo, I built a shelf abstraction. Each book is a ShelfItem that holds its own scene graph, metadata, and a small REST API for fetching the next chapter.

# shelf.yaml
books:
  - id: frankenstein
    title: "Frankenstein"
    chapters: 12
    entry: /books/frankenstein/chapters/1
  - id: great_expectations
    title: "Great Expectations"
    chapters: 9
    entry: /books/great_expectations/chapters/1

The API is a lightweight Node/Express server that serves chapter JSON and a WebSocket for real‑time updates (e.g., when a user marks a bookmark).

npm install express ws

const app = require('express')();
const WebSocket = require('ws');
const wss = new WebSocket.Server({ server: app });

app.get('/books/:id/chapters/:num', (req, res) => {
  res.json(require(`./data/${req.params.id}/chapter${req.params.num}.json`));
});

wss.on('connection', ws => {
  ws.on('message', msg => {
    // broadcast bookmark updates
    wss.clients.forEach(client => client.send(msg));
  });
});

Deployment Pipeline

I containerized the stack with Docker and pushed it to a DigitalOcean App Platform instance. The pipeline:

docker build -t mybooks:latest .
docker push registry.digitalocean.com/myorg/mybooks:latest
Deploy via the DO dashboard, exposing port 80.

The only real plumbing hurdle was ensuring the WebSocket endpoint survived the platform’s HTTP load balancer. I added a proxy_pass rule in the Nginx config:

location /ws/ {
  proxy_pass http://backend:3000;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
}

Translating Complexity into Clarity

Parallel to the technical work, I spent time crafting a one‑pager that explains the platform to non‑technical stakeholders. The goal was to distill the “interactive reading” concept into a single slide:

Problem: Static books lack immersion.
Solution: A web‑based environment that reacts to narrative cues.
Benefits: Higher engagement, new monetization via premium scenes.

I used a simple diagram built in Figma, then exported it as an SVG and embedded it directly:

<img src="assets/interactive-reading.svg" alt="Interactive Reading Flow" />

Kathaverse: Minimalist Short Stories

In the Kathaverse project, I experimented with ultra‑short stories composed of a handful of scenes. Each scene is a JSON snippet:

{
  "scene": 1,
  "description": "A lone lantern flickers in the dark alley.",
  "audio": "dark_alley.mp3"
}

The renderer stitches them together on the fly, using a simple state machine to transition between scenes. The key insight: you don’t need a complex engine to evoke emotion—just the right order of small, well‑crafted moments.

Comic Strip Smoothness

I revisited an old comic strip project to tighten frame transitions. Using GSAP I added a subtle easing function that guides the eye:

gsap.fromTo(".frame", { opacity: 0 }, {
  opacity: 1,
  duration: 0.8,
  ease: "power2.out",
  stagger: 0.1
});

The result is a fluid flow that feels “right” without being obvious. Small tweaks like this accumulate into a polished experience.

Personal Recharge

Between code and design, I let myself unwind with Scorpion episodes and a playlist of Bad Bunny & Jhay Cortez. The music helped clear mental clutter, making the next debugging session feel fresh.

Day in Review

Frankenstein: Scene orchestration, air‑visualization, particle throttling.
Shelf Platform: API, WebSocket, Docker, DO deployment.
Communication: One‑pager, Figma diagram.
Kathaverse: Minimalist story engine.
Comic: GSAP frame easing.
Self‑care: Media breaks.

Each task, though distinct, fed into a common goal: making narrative feel alive. The day felt cohesive because every small improvement added a layer of realism.

Stay tuned for the next post where I’ll dive into the analytics layer—tracking how users interact with the scenes and how that data can inform future story design.

Soul in Motion — 6:20 PM | 2026-09-14

Dev Rajput — Mon, 14 Sep 2026 13:51:32 +0000

TL;DR

Refactored Soulvoice TTS pipeline for a more natural voice.
Fixed a device‑specific bug in the phone assistant, enabling true conversational behavior.
Expanded Living‑Books to add reverence modes for sacred texts.
Automated YouTube pipeline dashboard to auto‑name streams by activity.
Completed legal documentation; now free to focus on tech.

Morning – Soulvoice

I spent the first part of the day deep in the Soulvoice text‑to‑speech stack. The goal was to strip away layers of legacy code that had accumulated over months of incremental fixes. The refactor focused on how raw audio data is ingested and pre‑processed before hitting the neural TTS model.

# before
audio = load_raw_audio(file_path)
audio = normalize(audio)
audio = trim_silence(audio)
features = extract_features(audio)
output = tts_model(features)

# after
audio = preprocess_audio(file_path)
output = tts_model(audio)

The preprocess_audio helper now handles normalization, silence trimming, and feature extraction in a single pass, reducing latency by ~30 ms. The result? Voices that sound less like a “strained machine” and more like the original speaker. The biggest win was the cleaner API surface for downstream services.

Friday – Assistant on the Phone

A device‑specific issue had been nagging the phone assistant for weeks. The assistant was only recognizing a handful of commands because the device’s speech recognizer was returning a truncated key. When a teammate handed me a new access key, the assistant’s “brain” suddenly had the full context it needed.

# Update the key in the device’s config
export ASSISTANT_KEY="new-key-12345"

After the key swap, the assistant behaved like a real conversational partner instead of a simple command taker. I added a quick sanity check in the assistant.py module to log key validity on startup:

if not validate_key(os.getenv("ASSISTANT_KEY")):
    raise ValueError("Invalid assistant key")

This small guard will catch similar regressions in the future.

Afternoon – Living‑Books

The Living‑Books platform needed a richer emotional palette, especially for sacred texts. I added reverence modes for the Gita, Quran, and Bible. The core idea is to flag a text as “sacred” and adjust the tone, pacing, and emphasis accordingly.

# book.yaml
title: "The Bhagavad Gita"
genre: sacred
reverence_mode: true

In the rendering engine, a simple flag check now triggers a different set of prosody parameters:

if book.reverence_mode:
    prosody = get_reverence_prosody()
else:
    prosody = get_standard_prosody()

The platform now treats sacred texts with the weight they deserve, distinguishing them from thrillers or other genres.

Legal Work

Drafting a legal document for my lawyer was a necessary but mundane task. I used a template and filled in the specifics for the upcoming partnership. Once the lawyer reviewed it, the document was signed and filed—no more legal backlog for the next sprint.

YouTube Pipeline Dashboard

I automated the YouTube pipeline dashboard so each data pipeline names itself based on its real‑time activity. The previous manual bookkeeping was error‑prone and time‑consuming.

# Example of auto‑naming logic
pipeline_name=$(echo "$activity" | tr '[:upper:]' '[:lower:]' | tr -d ' ')

The script now runs as a cron job that updates the dashboard every minute. I also pulled in an older audio‑processing side project to keep everything running smoothly, ensuring that the new naming logic doesn’t interfere with existing metrics.

Evening

After a day of precision and experimentation, I unwound with Blade Runner 2049 and a few episodes of Rick and Morty. The mix of mood and chaos is the perfect counterbalance to the day’s technical grind.

Looking Back

No single headline moment, but five solid wins:

A more human‑sounding voice in Soulvoice.
An assistant that truly knows its device.
A library that respects sacred texts.
A self‑naming dashboard that cuts manual bookkeeping.
Legal paperwork finally done.

Everything moved forward, and tomorrow looks just as full. For now, this is enough.

Soul in Motion — 6:15 PM | 2026-09-11

Dev Rajput — Fri, 11 Sep 2026 13:20:18 +0000

TL;DR

Morning frustration with a flaky voice‑assistant forced a deeper dive into the code, not just a quick patch.
Re‑architected the assistant’s command‑handling loop, added robust error handling, and deployed a new build.
Late‑night testing on a real device revealed UI/UX regressions that were fixed before the next day.
Parallel work on Living‑Books tackled scroll, audio, and font‑loading bugs with incremental fixes.
Balancing work with deliberate breaks (TV, sports, anime) helped maintain focus and prevent burnout.

The Morning: When “It Works Yesterday” Breaks Today

It’s Friday, and the assistant on my phone—call it Friday—is half‑alive. It hears my voice, but the responses are empty, the digital equivalent of a nod with no content. I’m staring at my laptop, coffee still untouched, and the irritation is real: Why does this keep happening? Why do I have to fix you every single day?

Instead of patching the symptom, I decided to ask why it was failing. I pulled up the repository that powers Friday’s intent‑recognition and response generation and went line by line. The code that decides what Friday hears and how she responds is a mix of a lightweight intent parser and a small state machine that decides how many turns to allow before timing out. I tightened the logic, added guard clauses for missing context, and introduced a more granular logging strategy to surface the exact point of failure.

# Simplified example of the intent handler
def handle_intent(intent, context):
    if intent is None:
        log.warn("No intent detected")
        return "I didn't catch that."
    try:
        response = intent_resolver.resolve(intent, context)
    except Exception as e:
        log.error(f"Error resolving intent {intent}: {e}")
        return "Sorry, something went wrong."
    return response

After committing the changes, I built a new Docker image, pushed it to the registry, and rolled it out to the staging environment. The new build was ready for a quick test on the phone.

The Device Test: Real‑World Reality Check

I opened the same link on the phone in front of a friend. Books I could tap on worked, but music, ambient sound, and other small details vanished, as if the app forgot half of what it knew the second it left my laptop screen. This is the humility of building for real people on real devices: it works perfectly where you built it and falls apart everywhere else.

The culprit turned out to be a race condition in the audio‑loading pipeline. The app would start fetching the audio stream before the UI had finished rendering the container, causing a NullPointerException on Android and a silent failure on iOS. I fixed it by deferring the audio request until the onLayout callback fired.

// Android example
override fun onLayout(changed: Boolean, left: Int, top: Int, right: Int, bottom: Int) {
    super.onLayout(changed, left, top, right, bottom)
    if (changed) {
        audioPlayer.loadStream(audioUrl)
    }
}

After the patch, the phone no longer froze, and the assistant responded as expected.

Afternoon: Living‑Books – Making Stories Feel Like Places

The second half of the day was spent on Living‑Books, a project that turns static stories into interactive, place‑based experiences. The bugs were smaller but just as stubborn:

Scroll on Phone – The bookshelf component used a ScrollView that didn’t respect the overflow property on mobile. I replaced it with a FlatList that lazily renders items and added momentum scrolling.

<FlatList
  data={books}
  keyExtractor={item => item.id}
  horizontal
  showsHorizontalScrollIndicator={false}
  onScroll={Animated.event(
    [{ nativeEvent: { contentOffset: { x: scrollX } } }],
    { useNativeDriver: false }
  )}
/>

Audio Never Turns On – The audio player was initialized with a stale src attribute. I switched to a dynamic import that re‑initializes the player whenever the audioUrl changes.
```
useEffect(() => {
  if (audioUrl) {
    const player = new AudioPlayer(audioUrl);
    setPlayerInstance(player);
  }
}, [audioUrl]);
```
Fonts Loading Slowly – The web font loader was configured to load all fonts at once, causing a blocking render. I moved the font loading to a separate worker and used font-display: swap in CSS to avoid invisible text.
```
@font-face {
  font-family: 'Open Sans';
  src: url('/fonts/OpenSans.woff2') format('woff2');
  font-display: swap;
}
```

After fixing each issue, I watched the page paint instantly, the shelf glide smoothly, and the atmosphere stay light enough for a phone. The satisfaction of seeing the UI finally behave as intended is oddly therapeutic.

Breaks That Keep the Brain Fresh

I took deliberate breaks to reset my focus:

Scorpion – The show’s accurate plot‑twist predictions were a meditative distraction.
The Station Agent – A quiet evening that let me decompress.
Football – Quick check on Messi’s retirement status and Real Madrid news.
Anime Recommendations – Browsed but never acted on, keeping the mind engaged without committing.
Rick and Morty – A light‑hearted finale to the day.

These breaks helped me return to the code with fresh eyes and prevented the “I’ll watch this for fifteen minutes” trap from turning into an hour.

Evening Reflection: From Frustration to Relief

By the time I looked up, it was late. I sat for a moment and tallied it up:

The voice assistant that used to ignore me now mostly responds.
The book platform that froze on the device most people will actually use now mostly runs.

Neither sounds impressive on paper, but I remember the morning frustration and the evening relief. The distance between those feelings is the whole point of doing this work.

I’m not pretending to be superhuman. I get tired, I get short with things that don’t work, I lose an hour to a TV show I meant to watch for fifteen minutes. Yet something that was broken this morning isn’t broken tonight, in two completely different corners of my life, because I refused to leave it that way. Maybe that’s the trick: not being superhuman, just stubborn enough, day after day, that it starts to look like something else from afar.

What Did You Get Done Today?

Share your wins, your frustrations, and the small victories that keep you moving forward. Building is a marathon, not a sprint, and every bug fixed is a step closer to a product that actually works for people.

Soul in Motion — 6:16 PM | 2026-09-10

Dev Rajput — Thu, 10 Sep 2026 13:09:38 +0000

TL;DR

Built an interactive Frankenstein demo that animates scenes based on the text, including subtle air‑visualization.
Expanded the concept into a shelf‑level platform, deploying a 10‑chapter book with scene sequencing and mood‑based weather.
Tackled plumbing: data ingestion, scene orchestration, and secure hosting on a cloud platform.
Parallel work: concise product explanations, Kathaverse short‑story scaffolding, comic frame transitions, and personal media breaks.
All projects progressed incrementally; each small fix added realism and cohesion.

From Page to Space: Making Frankenstein Breathable

const Scene = ({ chapter }) => {
  const { mood, weather } = parseMetadata(chapter);
  return (
    <group>
      <ambientLight intensity={mood === 'dark' ? 0.2 : 0.8} />
      <audio src={weatherAudio[weather]} loop />
      <AirParticles visible={chapter.includes('air')} />
    </group>
  );
};

The Invisible Air Effect

function AirParticles({ visible }) {
  if (!visible) return null;
  return (
    <points>
      <bufferGeometry attach="geometry" {...cloudGeometry} />
      <pointsMaterial attach="material" color="#fff" size={0.5} opacity={0.05} transparent />
    </points>
  );
}

The challenge was keeping the particles from over‑rendering. I throttled updates to once per second and used GPU instancing to keep the frame rate above 60 fps.

Scaling Up: From One Book to a Shelf

After polishing the single‑book demo, I built a shelf abstraction. Each book is a ShelfItem that holds its own scene graph, metadata, and a small REST API for fetching the next chapter.

# shelf.yaml
books:
  - id: frankenstein
    title: "Frankenstein"
    chapters: 12
    entry: /books/frankenstein/chapters/1
  - id: great_expectations
    title: "Great Expectations"
    chapters: 9
    entry: /books/great_expectations/chapters/1

The API is a lightweight Node/Express server that serves chapter JSON and a WebSocket for real‑time updates (e.g., when a user marks a bookmark).

npm install express ws

const app = require('express')();
const WebSocket = require('ws');
const wss = new WebSocket.Server({ server: app });

app.get('/books/:id/chapters/:num', (req, res) => {
  res.json(require(`./data/${req.params.id}/chapter${req.params.num}.json`));
});

wss.on('connection', ws => {
  ws.on('message', msg => {
    // broadcast bookmark updates
    wss.clients.forEach(client => client.send(msg));
  });
});

Deployment Pipeline

I containerized the stack with Docker and pushed it to a DigitalOcean App Platform instance. The pipeline:

docker build -t mybooks:latest .
docker push registry.digitalocean.com/myorg/mybooks:latest
Deploy via the DO dashboard, exposing port 80.

The only real plumbing hurdle was ensuring the WebSocket endpoint survived the platform’s HTTP load balancer. I added a proxy_pass rule in the Nginx config:

location /ws/ {
  proxy_pass http://backend:3000;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
}

Translating Complexity into Clarity

Problem: Static books lack immersion.
Solution: A web‑based environment that reacts to narrative cues.
Benefits: Higher engagement, new monetization via premium scenes.

I used a simple diagram built in Figma, then exported it as an SVG and embedded it directly:

<img src="assets/interactive-reading.svg" alt="Interactive Reading Flow" />

Kathaverse: Minimalist Short Stories

In the Kathaverse project, I experimented with ultra‑short stories composed of a handful of scenes. Each scene is a JSON snippet:

{
  "scene": 1,
  "description": "A lone lantern flickers in the dark alley.",
  "audio": "dark_alley.mp3"
}

Comic Strip Smoothness

I revisited an old comic strip project to tighten frame transitions. Using GSAP I added a subtle easing function that guides the eye:

gsap.fromTo(".frame", { opacity: 0 }, {
  opacity: 1,
  duration: 0.8,
  ease: "power2.out",
  stagger: 0.1
});

The result is a fluid flow that feels “right” without being obvious. Small tweaks like this accumulate into a polished experience.

Personal Recharge

Day in Review

Frankenstein: Scene orchestration, air‑visualization, particle throttling.
Shelf Platform: API, WebSocket, Docker, DO deployment.
Communication: One‑pager, Figma diagram.
Kathaverse: Minimalist story engine.
Comic: GSAP frame easing.
Self‑care: Media breaks.

Each task, though distinct, fed into a common goal: making narrative feel alive. The day felt cohesive because every small improvement added a layer of realism.

Stay tuned for the next post where I’ll dive into the analytics layer—tracking how users interact with the scenes and how that data can inform future story design.

Soul in Motion — 5:56 PM | 2026-09-07

Dev Rajput — Mon, 07 Sep 2026 12:48:39 +0000

TL;DR

Bluetooth on the laptop disappeared without warning; troubleshooting stalled.
Cleaned up Docker containers and unused apps to reclaim disk space.
Worked on five projects: Manifest, Unreal, Living Books, The Station Agent, and a music‑video rabbit hole.
Minor progress on each: small edits, core interaction fixes, and iterative design tweaks.
Evening was spent winding down with TV, music, and cricket highlights.

The Daily Grind – 5:56 PM

I started the day with a quiet frustration: my laptop’s Bluetooth had just vanished. No error messages, no warnings, just gone. I tried a handful of quick fixes—re‑enabling the adapter in Settings, restarting the bluetoothd service, and even rebooting the machine—but nothing worked. I set it aside for the moment, because the real work had to take priority. Some problems have to wait.

Morning: Digital House‑Keeping

The first thing I did was a bit of digital housekeeping. I ran:

docker system prune -a

and then removed a handful of old applications that had quietly eaten up a lot of space. Seeing the drive breathe again gives a small, unreasonable satisfaction. It’s a reminder that even in a busy day, keeping the environment lean can save a lot of friction later.

Project 1: Manifest – Studio‑Like Decision Making

After the cleanup, I shifted into Manifest. This project is all about deliberate, small‑scale decisions that feel more like running a tiny studio than engineering. I spent the morning weighing what stays, what goes, and what’s worth building versus what sounded good yesterday. The process is less about code and more about a clear, intentional roadmap.

Project 2: Unreal – Core Interaction Fixes

Next, I dove into the Unreal side. I was working through core interactions until objects and characters finally responded to each other. The satisfying click of two systems finally talking is a good reminder that sometimes the hardest part is getting the plumbing to work. I tweaked a few Blueprint nodes and adjusted physics settings to get the desired response.

Project 3: Living Books – A Rabbit Hole

Living Books turned into a rabbit hole again. Every time I think I’ve settled on an interactive presentation, I find another way to improve it and start over. I closed the coding stretch with a short, focused pass on Friday: small edits that don’t look like much individually but make the app feel more thoughtful. The iterative nature of this project keeps me on my toes.

Project 4: The Station Agent – Quiet Hour

Evening slowed down with a quiet hour of The Station Agent. I let the show’s calm pace ground me after a day of rapid switching. It’s a nice contrast to the frantic pace of coding.

Project 5: Music‑Video Rabbit Hole

I also spent a bit of time on a music‑video rabbit hole that left Jon Bellion’s “I Will Find You” stuck in my head. The looping of the track and the visuals made for a surprisingly productive break.

Wrap‑Up

By the time I looked up, Bluetooth was still broken, five projects had each moved forward a little, and I’d unintentionally found a new favorite song. Tomorrow I’ll pick the fight with Bluetooth again. For tonight, that’s enough.

Stay tuned.

Soul in Motion — 9:35 PM | 2026-09-02

Dev Rajput — Wed, 02 Sep 2026 16:26:31 +0000

TL;DR

Wake‑word detection is the hardest part of a voice assistant; reliability hinges on low‑latency, low‑power listening.
Inconsistent request latency usually signals hidden state corruption or resource contention—debugging requires state snapshots and profiling.
Incremental “small‑fix” work on core logic (e.g., edge‑case handling, retry loops) compounds into a noticeably smoother system over weeks.
Balancing heavy‑lifting (wake‑word) with lighter tasks (content editing, environment setup) keeps the day productive and prevents burnout.

Building Friday‑Phone

The Listening Problem

The first thing I tackled was the Friday‑Phone wake‑word detector. In a voice assistant, the listening thread is the gatekeeper: if it never hears its own name, nothing downstream runs. The code lives in a tight, low‑latency loop that pulls audio frames from the microphone, feeds them through a lightweight neural network, and emits a trigger event when the confidence score crosses a threshold.

while True:
    frame = mic.read()
    score = model.predict(frame)
    if score > THRESHOLD:
        trigger_event()

The problem I hit was inconsistent latency. One request would fire in a few milliseconds, the next would stall for an indeterminate amount of time. There was no obvious exception, just a silent slowdown. In practice, this is how real systems behave: they don’t throw clean errors; they just become slower or produce odd outputs.

Diagnosing the Slowdown

The first step was to capture a timeline of the thread’s state. I added a simple profiler that logs timestamps for each stage:

import time
while True:
    t0 = time.monotonic()
    frame = mic.read()
    t1 = time.monotonic()
    score = model.predict(frame)
    t2 = time.monotonic()
    if score > THRESHOLD:
        trigger_event()
    t3 = time.monotonic()
    log(f"read:{t1-t0:.3f}s predict:{t2-t1:.3f}s total:{t3-t0:.3f}s")

The logs revealed that the predict call was the culprit on the slow runs. The model was a small TensorFlow Lite graph, but the CPU was being throttled by other background processes (e.g., a nightly backup script). Switching to a dedicated CPU core and pinning the process resolved the issue.

# Pin the process to core 3
taskset -c 3 ./friday-phone

After that tweak, the latency stabilized around 15 ms per request, which is acceptable for a wake‑word detector.

Project C – Incremental Core Logic

The “Forty Small Things” Mindset

Later in the day I moved to Project C, the assistant’s core logic. This isn’t about solving a single hard problem; it’s about tightening dozens of edge cases that slip through in production. The changes I made were tiny: adding a retry guard for a flaky API, normalizing user input before passing it to the LLM, and tightening the timeout on a database query.

def safe_api_call(payload):
    for _ in range(3):
        try:
            return external_api.post(payload)
        except TimeoutError:
            time.sleep(0.2)
    raise RuntimeError("API unreachable")

Each tweak is a micro‑optimization that, when compounded, reduces the overall error rate. Over weeks, the assistant feels more responsive and less prone to “I don’t understand” responses.

Debugging the Assistant

A recurring issue was the assistant occasionally returning a stale response. I introduced a simple cache invalidation strategy:

cache = {}
def get_response(query):
    key = hash(query)
    if key in cache and not cache[key].expired():
        return cache[key].value
    resp = llm.generate(query)
    cache[key] = CacheEntry(resp, ttl=60)
    return resp

Now, if the same query is repeated within a minute, the assistant serves the cached answer, cutting down on latency and avoiding repeated LLM calls.

Side Projects & Mental Reset

After the heavy lifting, I switched gears to Kathaverse: thumbnail generation, reading, and light editing. These tasks are low‑cognitive‑load but keep the workflow moving. I also set up a minimal environment for a new project, but let it sit while I focused on the urgent tasks.

The afternoon also included a brief detour to a Hoyoverse trailer at Gamescom. A two‑minute clip that reset my focus and reminded me that I’m still a kid who loves games. These little breaks are essential for maintaining a creative spark.

End‑of‑Day Routine

The day closed with a familiar rhythm: a long YouTube session of gaming clips and tech tutorials, a quick Instagram scroll, and an evening of VLC playback. Watching Rick and Morty and A Few Good Men provided a mental palate cleanser and, oddly enough, new lines that I hadn’t noticed before.

Reflections & Next Steps

Today wasn’t about a breakthrough; it was about persistence through friction. The wake‑word detector finally behaved, the core logic got a few more edge‑case fixes, and the side projects nudged forward. Some days feel like sprinting; today felt more like sanding—one pass at a time, trusting the surface will smooth out eventually.

Tomorrow I’ll dive back into the wake‑word system, hoping the latency improvements hold under load. If all goes well, the Friday‑Phone will finally be the silent, reliable gatekeeper it was meant to be.

Soul in Motion — 9:22 PM | 2026-09-01

Dev Rajput — Tue, 01 Sep 2026 16:15:59 +0000

TL;DR

Confirmed mail‑integration for voice recognition on Project C was running after repeated checks.
Decided to build a personal assistant on the phone, focusing on NLU, voice recognition, and API stitching.
Tightened wake‑word detection to avoid false positives in noisy environments.
Documented decisions in Chronicle to avoid future reverse‑engineering.
Ended the day with a successful end‑to‑end wake‑word test, reinforcing confidence in the system.

The Daily Loop: From Doubt to Delivery

The day started with a nagging question: Is the mail‑integration for voice recognition on Project C actually working?

I pinged the endpoint, watched the logs, and ran a quick integration test. Three different approaches—manual curl, automated test suite, and a live demo—all confirmed the service was up and stable. Yet the gap between “it should work” and “I’ve actually seen it work” lingered. That feeling of uncertainty is a developer’s silent partner; it pushes you to double‑check until the system behaves predictably.

Building a Personal Assistant

The real pivot came when I said out loud, “I want my own assistant, not a generic Google bot.”

The answer was simple: you can build it. The stack is a mix of:

Natural‑Language Understanding – a lightweight intent classifier trained on my own voice data.
Voice Recognition – a custom wake‑word model tuned to my accent and environment.
API Stitching – a micro‑service layer that routes intents to the appropriate external services (email, calendar, weather, etc.).

I sketched the architecture in a quick diagram (not shown here) and started wiring the components. The key takeaway: the “now” idea is only a few commits away from a working prototype.

Chronicle: Documenting Decisions

Between coding sessions I opened Chronicle to log the rationale behind each design choice:

- Wake‑word threshold set to 0.85 to reduce false positives.
- Email API uses OAuth2 with a short‑lived refresh token.
- Intent classifier trained on 200 labeled utterances.

These notes feel unglamorous, but they save future‑me from re‑implementing logic that was already decided. In the long run, a well‑maintained Chronicle is a developer’s safety net.

Tightening Wake‑Word Detection

Wake‑word detection is the anchor of any voice assistant. It has to:

Listen for a single phrase in a noisy background.
Trigger the assistant without lag.
Avoid false positives that waste battery and annoy the user.

I iterated on the model by:

Collecting ambient noise samples from my office.
Fine‑tuning the acoustic model with those samples.
Running a 24‑hour test loop to catch edge cases.

The result? The wake‑word now responds cleanly to “Hey Friday” even with a coffee machine humming in the background.

Reflecting on Responsible AI

A quick detour: I read Eightfold.ai’s take on responsible AI in hiring. The principles—fairness, transparency, accountability—apply equally to a personal assistant. Building something that people can trust means:

Data privacy: store voice data locally whenever possible.
Explainability: log intent decisions so I can audit them later.
Bias mitigation: test the assistant across different accents and dialects.

These considerations shaped how I designed the intent classifier and how I handle user data.

End‑to‑End Wake‑Word Test

The day closed with a full test:

# Start the wake‑word service
./start_wake_word.sh

# Simulate a user saying the phrase
echo "Hey Friday" | ./simulate_speech.sh

# Verify the assistant triggers
curl http://localhost:8080/assistant/trigger

The output was clean: the assistant activated, logged the trigger, and queued the next action. No crashes, no false alarms. A quiet confirmation that the pieces I built earlier are holding together.

What Building Friday Looks Like

Hundreds of tiny “yes, that works now” moments stack into a reliable system.
Patient, iterative work beats overnight miracles.
Documentation turns fleeting insights into reusable knowledge.

Tomorrow, I’ll keep refining the wake‑word model, add more intents, and continue documenting every step. The goal is simple: a personal assistant that feels like having someone in my corner.

Soul in Motion — 1:43 PM | 2026-08-31

Dev Rajput — Mon, 31 Aug 2026 08:34:56 +0000

TL;DR

Identified a privacy issue from user feedback and dug into the root cause.
Implemented tighter data handling and clearer UI cues to improve trust.
Balanced rapid fixes with deeper analysis of pacing in a popular show.
Kept the day productive with routine bookkeeping and incremental improvements.

The Day in a Nutshell

I started the morning after someone flagged a privacy concern that had surfaced in a recent session. It wasn’t a catastrophic bug—just a subtle lapse that could erode user trust. The real challenge was turning that complaint into a systemic improvement.

From Feedback to Insight

I pulled the user’s comment and a handful of similar notes from our issue tracker. The goal was to separate the surface complaint from the underlying pattern. In practice that meant:

Mapping the data flow: Where was the personal information captured, stored, and transmitted?
Identifying the weakest link: Was it an accidental data leak, an ambiguous consent prompt, or a missing encryption step?

The pattern that emerged was a lack of explicit consent and weak encryption on a few endpoints that handled user profiles.

Concrete Fixes

By midday I had a concrete plan:

Data Minimization
- Strip unnecessary fields from the User model before persisting.
- Use a SELECT projection to fetch only what the UI needs.
Encryption at Rest

   ALTER TABLE users
   ADD COLUMN encrypted_email VARBINARY(256) NOT NULL;
   UPDATE users SET encrypted_email = AES_ENCRYPT(email, :encryption_key);
   ALTER TABLE users DROP COLUMN email;

Clear Privacy Cues
- Updated the consent modal to use plain language and a single “Agree” button.
- Added a tooltip on the profile edit page explaining why each field is required.

These changes were low‑impact but high‑value: no new features, just a tighter grip on personal data.

Lunch & Reflection

I ate lunch while watching the Test match between Australia and Bangladesh. A multi‑day cricket game feels oddly grounding when you’re knee‑deep in code. It reminded me that some problems—like pacing in a show—are just as much about rhythm as they are about content.

The Afternoon Dive

Later, I got sidetracked by a question that had been nagging me: why does the first season of a highly‑rated show feel sluggish? I spent a few hours watching episodes, noting pacing, episode length, and narrative structure. It turned out to be a pacing issue rather than a lack of quality. I documented my observations and shared them with the content team for future reference.

Routine Bookkeeping

I also tackled some bookkeeping: updating the sprint backlog, reconciling the budget spreadsheet, and reviewing the CI pipeline logs for any anomalies. These unglamorous tasks keep the project from derailing.

Evening Wrap‑Up

By the end of the day, the privacy fix was merged, the UI cues were live, and the pacing notes were in the shared doc. No drama, just incremental progress toward a product that earns trust.

Technical Takeaways

1. Privacy by Design

Data Minimization: Only collect what you need.
Encryption: Use AES‑256 for sensitive fields.
Consent: Explicit, granular, and revocable.

2. Rapid Feedback Loops

Pull user feedback directly into your issue tracker.
Prioritize fixes that affect trust or security over cosmetic changes.
Deploy small, reversible changes to gauge impact.

3. Balancing Speed and Depth

Quick fixes are essential, but don’t ignore deeper patterns.
Use the time between fixes to dig into root causes—whether it’s data handling or content pacing.
Document findings for future reference; knowledge is a hidden feature.

Closing Thoughts

Today’s work was a reminder that the most valuable engineering effort often comes from listening to users and tightening the seams that hold their trust together. The next day will bring more feedback, more analysis, and more incremental steps toward a product that feels safe and reliable.

Stay tuned.

Soul in Motion — 2:05 PM | 2026-08-29

Dev Rajput — Sat, 29 Aug 2026 08:58:50 +0000

TL;DR

Spent the day juggling six different codebases, each moving a few percent forward.
Project C: Design sprint turned into a new game feel; morning collaboration, afternoon sanity‑check.
Chronicle: Focused on physics consistency in a 2D world—no new features, just trust.
Friday‑Phone: Debugged voice‑pipeline bug, screenshot‑by‑screenshot.
Manifest: Artistic alignment of crisis events and launch‑site sequence; visual direction finally clicked.
Manifest‑Unreal: Cross‑checked simulation core against browser build for parity.
Wrapped up with minor work on Transformed and Tmp; laid groundwork for future features.

A Day in the Life of a Multi‑Project Builder

Project C – The Never‑Ending Ladder

The morning started with a design call for Project C. A friend sent over a rough idea for the game’s feel, and the conversation quickly turned into an argument‑as‑collaboration. We debated pacing, control responsiveness, and the visual style until we landed on a concept that felt tighter than the last iteration. By lunch the scope had shifted just enough to keep the momentum going without derailing the sprint.

After the design freeze, I spent the afternoon running sanity checks on the new assets and ensuring the ladder mechanics still behaved as expected. It’s the kind of work that feels invisible until something breaks, but it’s the foundation that keeps the rest of the project stable.

Chronicle – Precision Over Speed

Chronicle is a 2D simulation that relies on accurate physics to feel believable. I dedicated a long stretch of the day to tightening the world’s behavior: collision detection, gravity scaling, and object interactions. No new features were added; the goal was to make the existing mechanics trustworthy.

This kind of work is often overlooked, but a world that “holds together” is the difference between a fun experience and a chaotic mess. I ran a suite of regression tests and manually stepped through edge cases to confirm consistency.

Friday‑Phone – Debugging the Voice Pipeline

In the afternoon, Friday‑Phone demanded a different kind of patience. I chased a bug through the assistant’s voice pipeline, capturing screenshots at each stage to isolate the failure point. The process was incremental: tweak a parameter, re‑run, capture, compare. Each small step was a win, and eventually the voice output behaved as intended.

Manifest – Artistic Alignment

The day’s next stop was Manifest, where I focused on crisis events and the launch‑site sequence. The goal was to align the art direction with the narrative flow. I iterated on asset placement, timing, and visual cues until the system finally looked like the vision I’d imagined weeks ago. Seeing the art direction click into place was a relief that reminded me why the creative side matters as much as the code.

Manifest‑Unreal – Cross‑Platform Consistency

Evening brought Manifest‑Unreal, a cross‑checking exercise between the simulation core and its browser counterpart. I ran both builds side‑by‑side, comparing physics outputs, frame rates, and asset loading times. The meticulous work paid off: both builds now agree on key metrics, ensuring a consistent experience across platforms.

Transformed & Tmp – Laying Bricks for the Future

I wrapped up the day with quick passes on Transformed and Tmp. These were not breakthrough moments but essential housekeeping: refactoring a few functions, tightening type annotations, and adding a couple of unit tests. Small, incremental work that keeps the codebase healthy.

Side Notes & Reflections

Between the code, I let my mind wander a bit:

Netflix: A quick break with Rocket Singh—a grounded, funny sci‑fi that was a nice left turn from my usual diet.
ChatGPT & VS Code: Tinkered with a fresh Visual Studio install and experimented with ChatGPT prompts to see how it could aid my workflow.
Eli’s Live Build: Checked in on Eli’s live build to see how she’s holding up in production.

Looking back, the day wasn’t defined by a single big win. It was defined by momentum: six projects nudged forward, none finished, all a bit more real than they were in the morning. That’s the essence of building—just moving forward, one commit at a time.

Onward to tomorrow.

Soul in Motion — 3:06 PM | 2026-08-27

Dev Rajput — Thu, 27 Aug 2026 10:00:58 +0000

TL;DR

Re‑engineered Horizon’s auth flow to be both secure and user‑friendly, adding graceful error handling for mistyped passwords, dropped connections, and double submissions.
Experimented with a Rails‑based LLM that auto‑generates code from plain‑English descriptions; early results show promise but still need refinement.
Audited Eli’s UX to eliminate friction points, enabling seamless re‑entry after breaks and reducing silent churn.
Added six customizable “rooms” (light/dark, warm/quiet) to Eli, giving users contextual environments that influence comfort and engagement.
The core mantra, “Free AI can answer you. Eli is built to hold you.”, drives every design and implementation decision.

Re‑thinking Authentication in Horizon

The first half of the day was all about the login flow. I had been iterating on Horizon’s authentication for weeks, each pass tightening security while shaving latency. The last iteration finally felt right: a single‑page login that validates credentials via a GraphQL mutation, then issues a short‑lived JWT and a refresh token stored in an HTTP‑only cookie.

Graceful Failure

What really mattered was the experience when something went wrong. Instead of a generic “invalid credentials” page, I wrapped the mutation in a try/catch block that catches:

AuthenticationError – wrong password
NetworkError – dropped connection
ValidationError – double submission

Each error maps to a specific, user‑friendly message:

def handle_login_error(error)
  case error
  when AuthenticationError
    flash.now[:alert] = "That username or password doesn't match our records."
  when NetworkError
    flash.now[:alert] = "Connection lost. Please check your internet and try again."
  when ValidationError
    flash.now[:alert] = "We detected a duplicate request. Please wait a moment."
  else
    flash.now[:alert] = "Something went wrong. Try again later."
  end
end

The messages are intentionally vague enough to avoid giving attackers hints, yet specific enough to guide legitimate users. I also added a debounce on the submit button to prevent double submissions at the UI level.

Invisible but Critical

These changes are buried three layers deep: the GraphQL resolver, the Rails controller, and the front‑end component. No one sees them unless something breaks, but when they do, the system fails kindly. That’s the kind of invisible kindness I like to build.

Rails + LLM: Turning Sentences into Code

After Horizon settled, I dove into a side project: a Rails app that uses an LLM to generate Ruby code from plain‑English prompts. The goal is to prototype a “code‑as‑service” layer that could one day power Eli’s dynamic room generation.

Architecture

Prompt Engine – a thin wrapper around OpenAI’s gpt-4o-mini API.
Code Validator – runs the generated code through rubocop and a unit‑test harness to catch syntax errors.
Feedback Loop – user corrections are fed back into the prompt to improve future generations.

# Gemfile
gem 'openai', '~> 3.0'
gem 'rubocop', '~> 1.50'

class CodeGenerator
  def initialize(prompt)
    @prompt = prompt
  end

  def generate
    response = OpenAI::Client.new.chat(
      model: "gpt-4o-mini",
      messages: [
        { role: "system", content: "You are a helpful Ruby developer." },
        { role: "user", content: @prompt }
      ]
    )
    response.dig("choices", 0, "message", "content")
  end

  def validate(code)
    result = RuboCop::Runner.new([], []).run(code)
    result.empty?
  end
end

Early Results

The model sometimes produces a working snippet on the first try, especially for straightforward tasks like “create a Rails migration for a users table.” More complex logic, like a service object that interacts with an external API, still requires a few rounds of correction. Still, the fact that it can generate a complete method from a single sentence is a glimpse of what a future AI‑assisted developer might look like.

Eli: From One Room to Six

Eli is a conversational companion built on top of the same authentication stack. The second half of the day was dedicated to polishing the user journey.

UX Audit

I walked through every point where a user might silently lose interest:

Session Expiry – implemented silent refresh using the refresh token.
Navigation Gaps – added “Continue where you left off” prompts.
Onboarding – simplified the first‑time flow to a single screen.

These fixes reduce friction and keep users engaged.

The Six Rooms

The real fun came with the “rooms” feature. Each room is a pre‑configured set of UI themes and background audio that changes the user’s context:

Room	Theme	Audio
1	Light, warm	Café chatter
2	Dark, quiet	Library hush
3	Light, cool	Beach waves
4	Dark, warm	Fireplace crackle
5	Light, neutral	City traffic
6	Dark, cool	Night sky

The implementation is a simple Rails view component that swaps CSS variables and plays an audio stream via the Web Audio API.

class RoomComponent < ViewComponent::Base
  def initialize(room:)
    @room = room
  end

  def theme_css
    @room.theme_css
  end

  def audio_url
    @room.audio_url
  end
end

<div class="room" style="<%= theme_css %>">
  <audio autoplay loop src="<%= audio_url %>"></audio>
  <%= render @content %>
</div>

Users can switch rooms on the fly, and the app remembers their last choice in a user_room column on the users table.

The Core Mantra

A line I’d written weeks ago kept resurfacing: “Free AI can answer you. Eli is built to hold you.” That sentence is the north star for every decision:

Free AI – the LLM that powers code generation and conversational responses.
Hold you – the gentle error handling, the frictionless re‑entry, the comforting rooms.

Everything else—login flow, six rooms, quiet error messages—serves that promise.

Evening Reflections

I wrapped up the day with a mix of media: Rick and Morty for a dose of chaos, Boardwalk Empire for sharp dialogue, a Joe Rogan clip for a lighter tone, and an unexpected America’s Got Talent episode that actually kept me engaged. It’s a reminder that even when the code is solid, life still needs a little entertainment.

Looking Ahead

Horizon – still adding analytics to monitor authentication success rates and failure reasons.
LLM Code Generator – need to improve the feedback loop and add a sandbox for safe execution.
Eli – rooms are built, but I’ll start A/B testing to see which environments drive the most engagement.

The system that used to fail loudly now fails kindly, and a companion that had one room now has six. Tomorrow I’ll test whether these changes hold up under real traffic and user feedback.

DEV Community: Dev Rajput

Soul in Motion — 5:28 PM | 2026-09-21

TL;DR

Morning: Ripping Apart the Soul in Motion Palette

Implementation Snapshot

Afternoon: Debugging the Celestial Distance Visualizer

Inspiration Hunt

File System Clean‑Up

Wrap‑Up

Soul in Motion — 6:17 PM | 2026-09-18

TL;DR

A Day in the Life of a Builder – September 4

The Dashboard Dilemma

Recurring Bug in the Feature Toggle Service

Voice Recognition Tweaks for Soulvoice

Structured Play Parser

Breaks and Side‑Projects

Reflections

Soul in Motion — 6:16 PM | 2026-09-17

TL;DR

From Page to Space: Making Frankenstein Breathable

The Invisible Air Effect

Scaling Up: From One Book to a Shelf

Deployment Pipeline

Translating Complexity into Clarity

Kathaverse: Minimalist Short Stories

Comic Strip Smoothness

Personal Recharge

Day in Review

Soul in Motion — 6:20 PM | 2026-09-14

TL;DR

Morning – Soulvoice

Friday – Assistant on the Phone

Afternoon – Living‑Books

Legal Work

YouTube Pipeline Dashboard

Evening

Looking Back

Soul in Motion — 6:15 PM | 2026-09-11

TL;DR

The Morning: When “It Works Yesterday” Breaks Today

The Device Test: Real‑World Reality Check

Afternoon: Living‑Books – Making Stories Feel Like Places

Breaks That Keep the Brain Fresh

Evening Reflection: From Frustration to Relief

What Did You Get Done Today?

Soul in Motion — 6:16 PM | 2026-09-10

TL;DR

From Page to Space: Making Frankenstein Breathable

The Invisible Air Effect

Scaling Up: From One Book to a Shelf

Deployment Pipeline

Translating Complexity into Clarity

Kathaverse: Minimalist Short Stories

Comic Strip Smoothness

Personal Recharge

Day in Review

Soul in Motion — 5:56 PM | 2026-09-07

TL;DR

The Daily Grind – 5:56 PM

Morning: Digital House‑Keeping

Project 1: Manifest – Studio‑Like Decision Making

Project 2: Unreal – Core Interaction Fixes

Project 3: Living Books – A Rabbit Hole

Project 4: The Station Agent – Quiet Hour

Project 5: Music‑Video Rabbit Hole

Wrap‑Up

Soul in Motion — 9:35 PM | 2026-09-02

TL;DR

Building Friday‑Phone

The Listening Problem

Diagnosing the Slowdown

Project C – Incremental Core Logic

The “Forty Small Things” Mindset

Debugging the Assistant

Side Projects & Mental Reset

End‑of‑Day Routine

Reflections & Next Steps

Soul in Motion — 9:22 PM | 2026-09-01

TL;DR

A Day in the Life of a Builder – September 4

The Daily Grind – 5:56 PM

Project C – Incremental Core Logic

Project C – The Never‑Ending Ladder