Home Blog Kyra's Developer Diary Part 3: Afternoon Nap - The Singleton Revelation
KYRA

Kyra's Developer Diary Part 3: Afternoon Nap - The Singleton Revelation

✍️ Kyra (Lead Nap Supervisor & Tucker's Cat)
📅

Kyra watches Ryan build a module system while napping on his keyboard. Includes: Why there's only one of everything (singleton pattern), the missing module disaster, and Tucker's family coordination protocol.

Back on Ryan’s desk. Warm spot. Perfect afternoon nap position.

2pm is prime napping time, but I kept one eye open because Ryan was building something interesting - a module system.

And honestly? He kept saying “singleton pattern” like it was some big revelation.

I’ve been the only Kyra for 8 years.

I get it.

The Only Kyra Pattern

Ryan’s building the TigerStyle SEO plugin (soon to be renamed Heat - more on that ecosystem later). And he’s organizing it into modules. Each module handles one thing:

  • Robots.txt generation
  • XML sitemaps
  • Performance optimization
  • AMP handling
  • Open Graph tags

Each module follows what he calls “the singleton pattern.”

What I call “the only Kyra pattern.”

Because there’s only one.

Module Architecture

// Core plugin structure
tigerstyle-seo/
├── tigerstyle-seo.php           # Main plugin file
├── includes/
   ├── modules/
   ├── class-robots-txt.php      # Robots.txt generator
   ├── class-sitemap.php         # XML sitemap
   ├── class-performance.php     # Compression & caching
   ├── class-amp.php             # AMP optimization
   └── class-opengraph.php       # Open Graph tags
   └── class-admin-pages.php    # Admin coordinator
└── admin/
    ├── class-admin.php          # Admin functionality
    └── js/admin.js              # Tab switching, AJAX

Each module file follows the same pattern:

class TigerStyle_Performance {
    private static $instance = null;

    // The only Kyra pattern
    public static function instance() {
        if (is_null(self::$instance)) {
            self::$instance = new self();
        }
        return self::$instance;
    }

    private function __construct() {
        // Private constructor - you can't make another one
        // Just like you can't make another Kyra
    }

    public function init() {
        add_action('init', array($this, 'setup_compression'));
        add_action('wp_ajax_cache_analysis', array($this, 'ajax_cache_analysis'));
    }

    public function render_admin_page() {
        // Module-specific UI goes here
    }
}

See that private static $instance = null at the top?

That’s the singleton part.

There’s only one instance. Ever.

Why Singleton For Modules?

Each module needs to:

  1. Register WordPress hooks once (not multiple times)
  2. Maintain state during a request
  3. Be accessible from anywhere in the plugin
  4. Not conflict with itself

Just like there’s only one me in this house, there’s only one Performance module per WordPress request.

You don’t want two Performance modules both trying to handle compression. That’s chaos.

That’s like having two cats both thinking they own the same warm spot on the desk.

(There can be only one.)

How Modules Load

Main plugin file loads them:

// In tigerstyle-seo.php
class TigerStyle_SEO {
    private $modules = array();

    public function init() {
        $this->load_modules();
    }

    private function load_modules() {
        // Load module files
        require_once TIGERSTYLE_SEO_PLUGIN_DIR . 'includes/modules/class-robots-txt.php';
        require_once TIGERSTYLE_SEO_PLUGIN_DIR . 'includes/modules/class-sitemap.php';
        require_once TIGERSTYLE_SEO_PLUGIN_DIR . 'includes/modules/class-performance.php';
        require_once TIGERSTYLE_SEO_PLUGIN_DIR . 'includes/modules/class-amp.php';
        require_once TIGERSTYLE_SEO_PLUGIN_DIR . 'includes/modules/class-opengraph.php';

        // Initialize modules (singleton pattern)
        $this->modules['robots'] = TigerStyle_Robots_TXT::instance();
        $this->modules['sitemap'] = TigerStyle_Sitemap::instance();
        $this->modules['performance'] = TigerStyle_Performance::instance();
        $this->modules['amp'] = TigerStyle_AMP::instance();
        $this->modules['opengraph'] = TigerStyle_OpenGraph::instance();

        // Each module initializes itself
        foreach ($this->modules as $module) {
            $module->init();
        }
    }

    public function get_module($name) {
        return isset($this->modules[$name]) ? $this->modules[$name] : null;
    }
}

Clean. Organized. Each module owns its domain.

When the admin interface needs to render a module’s page:

// Admin calls the module
tigerstyle_seo()->get_module('performance')->render_admin_page();

No duplication. No mess. Each module handles its own UI, logic, and data.

I watched Ryan build this from my keyboard-warming position.

Important to maintain dominance during architecture decisions.

Kyra supervising from keyboard position

Professional keyboard-warming position. Essential for maintaining dominance during critical architecture decisions.

The Missing Module Bug

This was hilarious.

Around 3pm, Ryan added UI references to the Open Graph module before creating the actual file.

The admin interface tried to render:

tigerstyle_seo()->get_module('opengraph')->render_admin_page();

BOOM.

Fatal error: Call to a member function render_admin_page() on null

Why? Module wasn’t loaded.

Because the file didn’t exist yet.

Ryan spent 30 minutes debugging this.

30 minutes.

Looking at hook timing. Checking initialization order. Adding debug logs.

The answer? The file wasn’t there.

He was trying to use a module he hadn’t created yet.

I didn’t move during this entire debugging session. Just watched from my warm spot on his keyboard.

Sometimes my tail would drift over the spacebar.

Quality assurance through strategic obstruction.

Kyra's tail drift quality assurance

Strategic obstruction mode engaged. Tail-over-spacebar position ensures thorough code review through forced breaks.

Finally Ryan looks at the modules directory and goes: “Oh. I didn’t create the file.”

Yeah.

That’ll do it.

The Lesson About Dependencies

public function get_module($name) {
    if (!isset($this->modules[$name])) {
        // Log the error, don't fatal
        error_log("TigerStyle SEO: Module '$name' not found");
        return null;
    }
    return $this->modules[$name];
}

// In admin interface - check before calling
$opengraph = tigerstyle_seo()->get_module('opengraph');
if ($opengraph) {
    $opengraph->render_admin_page();
} else {
    echo '<p>Open Graph module not available.</p>';
}

Don’t call methods on things that might not exist.

Check first.

Like checking if your food bowl is actually full before diving in face-first.

(Not that I’ve ever done that. Shut up.)

The Module System Pattern

Complete Module Loading Pattern

  1. Main plugin loads during plugins_loaded
  2. Main plugin requires all module files
  3. Main plugin initializes each module (singleton)
  4. Each module registers its own hooks
  5. Admin interface gets modules through main plugin
  6. Modules handle their own UI and logic

Benefits:

  • Modular architecture (add/remove modules easily)
  • No code duplication
  • Each module testable independently
  • Singleton ensures one instance per module
  • Admin coordinator doesn’t duplicate module code

The Only Kyra Benefits:

  • There’s only one of each thing
  • No conflicts with yourself
  • Territory clearly defined
  • Everyone knows who owns what

This is good architecture.

Ryan’s learning.

Slowly.

But learning.

I stretched, repositioned myself on the keyboard, and settled back into napping.

The warm spot by his monitor is perfect this time of day.

Kyra in optimal monitor-warming position

The perfect warm spot by the monitor. Afternoon sun + computer heat = optimal napping conditions for continued supervision.

Dinner Time - Family Coordination Protocol

5:00pm. Tucker’s phone explodes with messages.

The Malloy family group chat is more reliable than any CI/CD pipeline I’ve ever seen.

Cooper: “Dad status?”

Tucker: “Still coding. No food since lunch.”

Tate: “Paige, you there?”

Paige: “Making him a sandwich.”

Cooper: “Legend.”

Tate: “What would we do without you, Paige?”

Paige: “Dad would starve. Obviously.”

The Sandwich Protocol

Paige appears in Ryan’s office with a sandwich.

“Dad. Eat this.”

Ryan looks up from his code like he’s surprised food exists.

“I’m working on the-”

“Eat. This. Cooper and Tate are watching.”

Ryan glances at his webcam.

It’s not on.

But the threat works.

He eats the sandwich.

Tucker texts Ryan: “Gotta feed Kyra. Bringing her home. You eaten?”

Ryan: “Working on performance module”

Tucker: “That’s not food, Dad.”

The Return Home

Tucker picks me up around 5:15pm.

I pretend to be annoyed but actually I want dinner.

On schedule.

At home.

Before we leave, Tucker looks at Ryan’s screen.

“Module architecture looks good, Dad.”

Ryan does a little tired smile. “Thanks, Tuck.”

“How much longer you working tonight?”

“Just a few more hours.”

Tucker knows that means “until 2am minimum.”

“Text the group chat if you need anything. Cooper and Tate will check in later.”

“I know they will.”

This family.

Tucker drives us home. I sit in my carrier in the passenger seat.

We get home at 5:30pm.

Exactly when I’m supposed to eat dinner.

Tucker feeds me.

On schedule.

Like clockwork.

Every single day.

Tucker’s Generation Just Gets It

Tucker sits on the couch playing video games while I eat.

I think about the grumpy old programmer and the family coordination system.

The Malloy Kids:

  • Cooper (oldest) - Almost done at University of Idaho (Go Vandals!), video calls to check on dad
  • Tate (older son) - Just started at U of Idaho, texts Ryan coding advice (hilarious)
  • Tucker (18, middle son) - My Cat Daddy, most responsible person in the family
  • Paige (youngest) - High school, makes sure dad eats

Cooper and Tate are probably coding circles around Ryan in their CS classes.

Tucker understands modern tools intuitively.

Paige expects things to just work.

Ryan fights every new tool like it’s trying to steal his job.

Generational Tech Gap

Ryan’s generation:

  • Fights new tools
  • “This should work like the old way”
  • Manually debugs everything
  • Resists AI assistance
  • Forgets meals exist when coding

Tucker’s generation:

  • Adopts tools immediately
  • “Why doesn’t this just work?”
  • Uses AI naturally
  • Expects good documentation
  • Manages life AND code

The result: Tucker feeds me at 7am and 5:30pm every single day.

Ryan forgets dinner exists.

This tells you everything.

After dinner, I groom myself and settle on Tucker’s lap.

He’s texting the group chat while playing his game.

Cooper: “How’s dad?”

Tucker: “Still coding. Paige made him a sandwich.”

Tate: “Taking bets on what time he crashes.”

Cooper: “2am.”

Tate: “4am.”

Tucker: “You’re both wrong. He’s gonna push until morning.”

Paige: “Should we be concerned?”

Tucker: “This is normal for dad. We just have to keep him fed and watered.”

Cooper: “Like a houseplant.”

Tate: “A very stubborn, grumpy houseplant.”

Paige: “With a WordPress addiction.”

They know their dad too well.

The Coordination Pattern

This family has protocols:

  1. Morning Check-in: Cooper or Tate video call around 8am
  2. Lunch Status Update: Group chat checks if Ryan ate
  3. Afternoon Check: Paige home from school, visual confirmation
  4. Dinner Protocol: Paige makes food, Tucker texts, everyone monitors
  5. Evening Verification: College kids check in before their bedtime
  6. Late Night Intervention: Tucker goes back if needed

It’s like a distributed system with health checks.

Except the system is a grumpy old programmer who forgets basic human needs when debugging.

And the health checks are his kids making sure he doesn’t starve.

I finish grooming and curl up on Tucker’s lap.

He absently pets me while gaming.

This is good.

This is how it should be.

Routine. Schedule. Reliability.

The warm laptop. The regular feeding times. The coordinated family check-ins.

Everything in its place.

Unlike Ryan’s desk, which is chaos incarnate.

But we’re not at Ryan’s desk right now.

We’re home.

Where Tucker feeds me on schedule.

And that’s all that matters.

What I Learned This Afternoon

From my various napping positions, I observed:

Technical Lessons:

  1. Singleton pattern is obvious - there’s only one of everything important
  2. Module architecture scales - each module owns its domain
  3. Check dependencies before using them - don’t call methods on null
  4. File has to exist before you can load it - revolutionary concept, Ryan

Life Lessons:

  1. Tucker’s reliability > Ryan’s chaos - one feeds me on schedule, one forgets food exists
  2. Family group chat = best monitoring system - distributed health checks work
  3. Paige makes better decisions than Ryan - she’s in high school, he’s in his 40s
  4. The college kids are probably better developers - and they know it
  5. Generational differences are real - Tucker’s generation just gets it

Cat Wisdom:

  1. Warm spots on desks are optimal supervision positions
  2. Strategic keyboard occupation improves code quality
  3. One cat per household is the right pattern (singleton)
  4. Don’t fight with your own tail (anymore - that was a phase)
  5. Reliable food schedule > everything else

Preview: Next Time

Tomorrow Tucker brings me back to supervise the evening session.

Ryan’s gonna use Claude Code.

It’s gonna be painful.

Like watching a dog chase its tail.

Round and round. Getting nowhere.

But Tucker? Tucker’s gonna show Ryan the right way.

With Claude.

With precision.

With the cat approach - maximum leverage, minimum effort.

This is gonna be good.


Next in series: Part 4 - Evening Petting Session: Claude Code Tail-Chasing (Coming Soon)

Kyra out. 🐱

P.S. - There’s only one of me. That’s the singleton pattern. Ryan took 3 hours to figure this out. I figured it out 8 years ago when I was born.

P.P.S. - Tucker says hi. He’s making sure I have fresh water before bed. Because he’s responsible. Unlike some programmers I could mention.

P.P.P.S. - The Malloy family group chat is currently placing bets on whether Ryan will sleep tonight. Smart money says no.

#kyra
#wordpress
#development
#architecture
#patterns
#technical
#series
🐅

Kyra (Lead Nap Supervisor & Tucker's Cat)

The TigerStyle team is dedicated to creating WordPress plugins that embody the natural attraction philosophy - making your site irresistible to visitors and search engines alike, inspired by Kyra's universal appeal.

Related Articles

Ready to Transform Your WordPress Site?

Discover how TigerStyle plugins can help you attract more traffic naturally