For decades, the study of mental health has grappled with a fundamental challenge: how do we understand the dynamic, often unpredictable, nature of psychological change? Why do some individuals remain stuck in persistent states of depression, while others “bounce back” with remarkable resilience? And how can we anticipate sudden shifts in behavior, like a relapse or a breakthrough in therapy?

A powerful new perspective comes from complex systems science, which reframes mental health not as a static condition but as an emergent property of a dynamic system. This approach uses the “ball-and-landscape” metaphor: our psychological state is a ball rolling across a landscape of valleys and hills. The valleys are attractor states—stable, self-organizing patterns that our system naturally gravitates towards and resides in. A deep valley represents a robust state, like chronic depression or, conversely, a state of resilient well-being. The hills represent unstable transition zones.

This perspective is transformative because it allows us to see:

• Healthy and Pathological States as Attractors: Both well-being (resilience) and psychopathology (e.g., persistent sadness) are viewed as stable dynamic patterns.
• Clinical Change as Phase Transitions: Sudden shifts, like recovery or relapse, are seen as “phase transitions,” where the system tips from one attractor valley into another. These transitions can be of different types, such as bifurcation-induced tipping (B-tipping), caused by a gradual change in the landscape itself, or noise-induced tipping (N-tipping), caused by a sudden, large perturbation.
• Intervention as Landscape Design: Therapy and other interventions can be understood as efforts to reshape this landscape—to shallow a “depression” valley or deepen a “well-being” valley.

The predictive power of this model is immense. As a system’s current attractor state becomes unstable and approaches a B-tipping point, it exhibits tell-tale signs like critical slowing down (slower recovery from minor setbacks) and critical fluctuations (increased behavioral variability). These are “early warning signals” that a major transition is imminent, creating a window for just-in-time interventions.

But this powerful metaphor raises a critical scientific question: Can we move beyond the metaphor? Can we use real-world data to empirically identify these hidden attractor states and test their properties? My goal was to develop a rigorous statistical methodology to answer a critical question: Can we use real-world time series data to not only identify distinct hidden states but also to test whether those states qualify as bona fide attractors?

I discovered that Hidden Markov Models (HMMs) offer a powerful toolkit for this exact purpose. Instead of assuming that the hidden states an HMM identifies are attractors, my approach uses the various outputs of a fitted HMM as a suite of metrics to either support or refute this claim.

This document outlines the framework I developed for this investigation, a crucial conceptual insight that emerged, and a practical guide to implementing this validation process in R.

A Framework for Testing Attractor State Characteristics

The first step was to deconstruct the “attractor” concept into its core, testable properties. An attractor is a state that a system is drawn towards, resides in, and resists leaving. I translated these properties into a set of hypotheses that could be evaluated using HMM parameters.

Crucially, the interpretation of the evidence is not black-and-white. A given metric might provide strong evidence for the existence of a stable pattern, while another might offer more nuanced information about the type of stability or the likelihood of a specific kind of transition.

The “Engine vs. Dashboard” Insight: A Key to Correct Inference

A critical conceptual hurdle emerged during this work. I initially worried that the HMM’s core assumption—that the current hidden state depends only on the immediate past state (the Markov property)—would artificially limit my analysis to simple, lag-1 dynamics. This, however, is a misunderstanding of how the HMM’s two-layer structure works, and correcting it is essential for making valid inferences.

The “Engine vs. Dashboard” analogy proved invaluable:

1. The Hidden “Engine” (The State): This is the underlying, unobserved state we are testing (e.g., a state of Severe Depression). The simple lag-1 Markov rule applies only here.
2. The Observed “Dashboard” (The Data): This is what we measure (e.g., daily depression scores). These scores are emitted by the hidden engine state.

The link between them is state inertia. If the Severe Depression state is a true attractor, its inertia will be high (P(Depression|Depression) ≈ 1). This persistence means that even though the state-switching rule is simple, the observed data will exhibit long-range memory. A high depression score today will be correlated not just with tomorrow’s score, but with the score ten days from now, because all are likely generated by the same, persistent underlying state. This allows us to use the full autocorrelation structure of the data as a rich source of evidence without being constrained by the model’s internal mechanics.

Practical Implementation: A Guide to R’s depmixS4 Package

With the validation framework established, the final step was to operationalize it. The R package depmixS4 is perfectly suited for this task. The workflow involves specifying a model with depmix(), fitting it with fit(), and then using the resulting depmix.fitted object (which I’ll call fm) to extract the metrics needed to test our hypotheses.

Here’s the complete guide on how to gather the evidence using fm:

# After fitting a model: fm <- fit(mod)
# 1. View the transition matrix in the summary output
summary(fm)
# 2. To derive expected duration for state 1:
inertia_s1 <- # (get value from summary)
exp_dur_s1 <- 1 / (1 - inertia_s1)
        

# 1. Get the transition probability matrix (tpm) from summary(fm)
# 2. Use a helper function (not in depmixS4) to compute MFPT
mfpt_matrix <- calculate_mfpt(tpm)
        

# 1. View the response parameters in the summary output
summary(fm)
# 2. Programmatically get the response model for state 1, response 1
response_s1 <- getmodel(fm, which = "response", state = 1, number = 1)
# The mean is a parameter within this object
getpars(response_s1)
        

# View the response sd or Sigma matrix in the summary output
summary(fm)
# Programmatically access using getmodel() as shown for the mean.
        

# 1. For Stationary Distribution (conceptual):
tpm <- matrix(c(0.9, 0.1, 0.2, 0.8), 2, 2, byrow=TRUE)
stationary(tpm)
# 2. For Fractional Occupancy:
state_sequence <- posterior(fm, type = "global")$state
table(state_sequence) / length(state_sequence)
        

# The "Transition probabilities" section of the summary is the metric
summary(fm)
        

# 1. Specify covariate in model:
mod <- depmix(..., transition = ~ Pacc, ...)
fm <- fit(mod)
# 2. View the coefficient for Pacc in the summary output
summary(fm)
        

# 1. Simulate a long time series from the fitted model
sim_data <- simulate(fm, nsim=10000)
# 2. Compute ACF on the simulated response
acf(sim_data$response)
        

# Look at off-diagonal values in the transition matrix from:
summary(fm)
        

Conclusion

This work culminated in a robust, data-driven methodology for using HMMs as an investigatory tool. We no longer need to simply assume that the hidden states identified by a model are attractors. We can now subject them to a battery of statistical tests, using the model’s own parameters as evidence. This approach allows us to build a case for or against a state’s status as an attractor, and more importantly, to begin hypothesizing about the types of transitions a system is prone to. It moves the complex systems approach from a powerful metaphor to a testable scientific framework, unlocking new possibilities for predicting and influencing psychological change.

July 5, 2025

In our previous guide, we built the ultimate bridge between a MacBook and a Windows powerhouse, enabling a full-featured VS Code development experience inside WSL2. We set up port forwarding, configured the firewall, and established a solid connection.

But there’s one lingering piece of friction in that workflow: the password prompt.

Every time you connect, VS Code asks for your Ubuntu user’s password. It’s a small interruption, but it stands in the way of a truly seamless, one-click experience.

In this guide, we’ll eliminate that final hurdle. We’ll replace password authentication with a more secure and convenient method: SSH keys. By the end, you’ll be able to launch your remote VS Code session without ever typing a password again.

The Big Picture: Keys vs. Passwords

An SSH key pair is like a sophisticated lock and key for your digital world.

• The Public Key (The Lock): You can freely share this and install it on any server you want to access. It acts as a lock that only your private key can open.
• The Private Key (The Key): This is your secret. You keep it safe on your local machine (your MacBook). It can unlock any system that has your public key installed.

This method is vastly more secure than a password, which can be guessed or brute-forced. Let’s get it set up.

Part 3: Upgrading to Key-Based Authentication

This guide assumes you have completed the steps in our original article. We’ll be modifying that setup.

Step 1: Create Your SSH Key Pair (Inside WSL2)

First, we need to generate our secure keys inside the Ubuntu environment.

On your Windows machine, launch your Ubuntu WSL2 terminal and run the following commands.

1. Generate the Key Pair We’ll use ed25519, a modern and highly secure algorithm.

# This will start the key generation process
ssh-keygen -t ed25519

You will be prompted for two things:

• File to save the key: Press Enter to accept the default location (~/.ssh/id_ed25519).
• Enter passphrase: This is highly recommended! A passphrase is a password that encrypts your private key on disk. It ensures that even if someone steals your private key file, they can’t use it without the passphrase. We’ll see how to avoid typing it constantly in a later step.

2. Authorize Your New Key for Login Now, you need to tell your Ubuntu server that this new key is allowed to log in. You do this by adding the public key to a special file called authorized_keys.

# Add the public key to the list of authorized keys
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

# Set strict permissions, which SSH requires for security
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Your WSL2 instance is now ready to accept a connection using your new key.

Step 2: Configure Your MacBook to Use the Key

Now, let’s go back to your MacBook and teach it how to use this new, more secure method.

The following steps are performed on your MacBook terminal.

1. Securely Copy the Private Key to Your Mac The private key (id_ed25519) needs to be on your Mac to authenticate.

First, display the key’s content in your WSL2 terminal so you can copy it.

# In your WSL2 terminal
cat ~/.ssh/id_ed25519

Select and copy the entire output, including the -----BEGIN OPENSSH PRIVATE KEY----- and -----END OPENSSH PRIVATE KEY----- lines.

Now, on your Mac, create a file to store this key.

# In your macOS terminal
# Create a new file for the key and set secure permissions
touch ~/.ssh/wsl2_key
chmod 600 ~/.ssh/wsl2_key

# Open the file in a text editor to paste the key
nano ~/.ssh/wsl2_key

Paste the private key you copied from WSL2 into this file, then save and exit (in nano, that’s Ctrl+X, then Y, then Enter).

2. Update Your VS Code SSH Config In the previous guide, we added a host to the ~/.ssh/config file. Now we just need to tell it which key to use.

Open ~/.ssh/config on your Mac and find the host entry for your WSL2 connection. Add the IdentityFile line to it:

# In ~/.ssh/config on your MacBook

Host 192.168.0.113 # Or whatever you named your host
    HostName 192.168.0.113
    User your-wsl-username
    Port 2222
    # Add this line to specify which key to use!
    IdentityFile ~/.ssh/wsl2_key

Now, when you try to connect, VS Code will use your SSH key instead of asking for a password. However, it will ask for the key’s passphrase. Let’s fix that.

Step 3: The Final Polish - Automating the Passphrase

We need a way to unlock our private key once and have it stay unlocked for our entire work session. This is exactly what ssh-agent is for. It’s a secure background utility that holds your unlocked keys in memory.

We can configure your Mac’s shell to start the agent and load your key automatically.

Add the following lines to the end of your shell configuration file on your Mac (~/.zshrc for Zsh, or ~/.bash_profile for Bash).

# Auto-start ssh-agent and add my WSL2 key on terminal launch
if ! pgrep -u "$USER" ssh-agent > /dev/null; then
    ssh-agent > ~/.ssh/ssh-agent.env
fi
if [[ ! "$SSH_AUTH_SOCK" ]]; then
    source ~/.ssh/ssh-agent.env >/dev/null
fi
ssh-add -l | grep -q wsl2_key || ssh-add ~/.ssh/wsl2_key

Now, close and reopen your terminal. The very first time, it will prompt for the passphrase for your wsl2_key. Enter it one last time.

The Final Result: True One-Click Connection

That’s it! The ssh-agent will now remember your unlocked key.

Open VS Code, go to the Remote Explorer tab, and click the connect icon next to your WSL2 host. It will connect instantly, with no password and no passphrase prompt.

You have now perfected your cross-platform setup. Your connection is not only more convenient but also significantly more secure. You’ve replaced a brittle password with strong public-key cryptography and automated the entire login process.

Happy (and seamless) coding! 🚀

A curious thought has occupied me recently. It revolves around the fundamental unit of our written work: the paragraph. We often treat a paragraph as a singular, atomic thing, but what if it’s more like a composite structure? What if a single collection of facts or ideas could be assembled in fundamentally different ways to achieve entirely different effects? It seems to me that the form of the delivery is just as crucial as the content being delivered, and I wanted to document some of my own thinking on how one might begin to formally separate these concerns.

A Functional Model of the Paragraph

To get my own head around this, I started thinking about a kind of three-tiered functional model. This isn’t meant to be a rigid prescription, but rather a way of organizing the different jobs a paragraph does.

• Level 1: The Structural Role (The “Where”). This seems to be the highest level, defining the paragraph’s job within the entire document. Is it an Introductory paragraph, setting the stage? Is it a Body paragraph, doing the heavy lifting of the argument? Or is it a Concluding paragraph, bringing things to a satisfying close? Its position dictates its overarching function.

• Level 2: The Communicative Purpose (The “Why”). Once we know where it is (e.g., a Body Paragraph), we can ask why it exists. What is its core intent? I see four main purposes here. Is it Expository, aiming to explain or inform? Is it Persuasive, built to convince the reader of a claim? Is it Descriptive, trying to paint a sensory picture? Or is it Narrative, recounting a sequence of events?

• Level 3: The Method of Development (The “How”). This is the most granular level, the internal architecture. How is the paragraph built to achieve its purpose? This is where we find the familiar rhetorical strategies: Compare and Contrast, Cause and Effect, Problem-Solution, Exemplification, and so on.

The interesting part, for me, is the dependency. The choice of Structural Role (Level 1) constrains the Purpose (Level 2), which in turn strongly suggests a Method (Level 3). It’s a cascade from general architecture to specific implementation.

An Experiment in Generative Composition

As a playful exercise to see this model in action, I put together a small Python script. The idea was simple: could I take a set of “core content”—just raw notes and facts about a topic—and use this three-tiered model to instruct a generative AI to assemble that content into different paragraph forms? The script simply takes the core content, a chosen purpose from Level 2, and a chosen method from Level 3, and asks the model to write the paragraph accordingly. It’s a way of operationalizing the theory.

Observing the Model in Action

The results were quite striking. Watching the same set of core concepts get refracted through different purposeful and methodological lenses is fascinating. Here are two examples generated by the script, both using the exact same source material but with different instructions.

Shared Inputs

• Core Concepts:
  • Concept: Human systems can have multiple points of equilibrium, representing different long-term steady-state behaviors.
  • Equilibrium Points: Can be stable (system tends to return) or unstable (system moves away). They generally correspond to a system’s lowest energy state.
  • Linear vs. Nonlinear Dynamics: Linear systems typically have one equilibrium state, whereas nonlinear systems can have multiple possible “comfortable” long-term states.
  • State Switching: Perturbations can cause the system to shift from one equilibrium state to another.
  • Examples in Humans: This applies to psychological states (focused vs. unfocused), psychophysiological states (relaxed vs. stressed), and behavioral states (cooperative vs. independent).
  • References: (Allen & Carifio, 1995; Chow et al., 2015; Moulder et al., 2023).

Example Generated Paragraphs

Broader Musings: Towards a “Clean Architecture” for Research

My first reaction to seeing this work was, well, a sense of amusement. It’s quite something to see a machine play with argumentation structures so fluidly. But it quickly led to a deeper line of thought. It really forces one to question the nature of authorship in an era where the framework that delivers information can be generated so easily. It seems less realistic, and perhaps less important, for individuals to focus on the fine-grained mechanics of paragraph construction. The real skill might be shifting to a higher level: a deeper understanding of argumentation itself, of rhetorical architecture, and of the audience one is trying to reach.

This is where my mind wanders to ideas from software engineering, specifically the concept of “clean architecture.” The principle there is to separate the core business logic—the truly essential stuff—from the delivery mechanisms like databases or user interfaces. I wonder if a similar pattern could be applied to research. The final output—the formal paper—is really just one possible delivery mechanism. The more fundamental “core” is the research project itself: the data, the core concepts, the key findings.

If one can successfully extract that core and hold it as a distinct entity, one could then, in theory, pipe it into any number of frameworks for dissemination. The same core research could be rendered as a formal academic paper for a peer-reviewed journal, a persuasive opinion piece for a broader audience, a series of blog posts, or a conference presentation. Each output would simply be a different “view” of the same underlying entity, tailored to a specific medium and audience.

This little script and the model behind it are, of course, just a bit of experimental fun. But they feel like a small, playful step toward conceptualizing this kind of “clean architecture research environment.” It feels like a way to spend less time on the syntactical details and more time on the deep architecture of our work, which, to my mind, is a fascinating possibility to consider.

This post muses on a potential computational framework for psychopathology, built around two tentative ideas:

• Internal Agents: The mind could perhaps be viewed as a system of interacting “agents” (e.g., a “self-critic,” “problem-solver”) that seem to influence mood and behavior.
• External Events: Life stressors might be conceptualized as probabilistic streams, reflecting their likelihood of happening over time.

Connecting these concepts could suggest a lens for thinking about intervention, pointing toward possible ways to either address external factors or foster more adaptive internal responses.

I had a curious thought cross my mind today, a sort of conceptual model for thinking about the dynamic nature of our internal worlds. It’s a way to bridge systems thinking, psychopathology, and some of the newer tools in computational modeling. This idea is in it’s infancy, and this represents my first attemp to get down the basics.

The idea begins with a framework I often come back to: modeling psychological distress, like suicidality, as a network of interacting factors. We often talk about internalizing factors (like rumination or negative self-talk) and externalizing factors (like impulsivity or aggression). We can visualize these as nodes in a directed acyclic graph (DAG), showing how one symptom can trigger another.

But here’s the thought that struck me as new: what if we modeled these internal factors not just as static nodes, but as agents?

The Internal System: A Society of Agents

Imagine the internal world as a collection of different “parts” or “voices,” a concept seen in therapeutic approaches like Internal Family Systems Therapy. It’s the idea that within us, we have different roles that take the lead at different times. There might be a “social planner,” a “harsh critic,” an “anxious protector,” or even a “wise advocate.”

Now, what if each of these parts was a computational agent, maybe even powered by a large language model? Each agent would have its own function, its own level of competence, and its own triggers for activation. When faced with a challenge, the system would “call upon” different agents to help regulate emotion or plan a response.

A system like this would be incredibly dynamic. The overall mood or behavior of the person wouldn’t be a simple sum of its parts, but an emergent property of the interactions between these agents. You could have a highly competent “internal clinical psychologist” agent that suggests helpful behavioral strategies, but it might be rarely activated because a louder, more reactive “anxious protector” agent always jumps in first.

This moves beyond thinking about intervention as simply a list of behavioral techniques. It frames it in a more dynamic, language-based way. How do we help the system learn to call on its more adaptive agents? How do we bolster the skills of a struggling agent?

The External World: A Probabilistic Stream of Events

Of course, our internal system doesn’t operate in a vacuum. It’s constantly being influenced by the outside world. This is the second piece of the puzzle: modeling contextual factors.

Life events—a negative comment from a boss, a fight with a partner, getting good grades, a delayed train—are inputs that can either regulate or dysregulate our internal system. The interesting part is that while we can’t predict exactly when a specific negative event will happen, we can often model its general rate of occurrence.

A tool like a Poisson distribution immediately comes to mind, and it may be quite suitable for this. It’s used to model the probability of a given number of events happening in a fixed interval of time, assuming these events occur independently and at a constant average rate. So, for a person experiencing chronic social friction, their “negative social event” category would likely have a high rate of occurrence—a high lambda ($\lambda$) value, in statistical terms. This mathematically captures the idea of a continuous “stress load” that bombards the individual’s internal system. One could imagine having different probabilistic models for different categories of life events: work, social, health, etc. This would need to be considered more carefully, obviously.

Bringing It All Together in a Unified Framework

This is where the directed acyclic graph comes back in. A DAG could visualize the entire system:

1. External Event Nodes: These would be the probabilistic generators of life stressors, like “Academic Stress” or “Relationship Conflict,” each with its own rate of occurrence modeled by a Poisson distribution.
2. Internal Agent Nodes: These are the internal voices, like the “Self-Critic,” “Social Planner,” or “Problem-Solver.”
3. State Nodes: These could represent mood, anxiety levels, or energy.

The edges of the graph would show the influence. An event from the “Academic Stress” node (e.g., a bad grade) might activate the “Self-Critic” agent. The “Self-Critic” agent, in turn, would strongly influence the “Mood” state node in a negative direction. Meanwhile, a positive event might activate a different, more helpful agent.

A Conceptual Path to Intervention

Thinking about this as a case formulation is what really excites me. It makes the potential targets for change so clear. You could intervene in two fundamental ways:

1. Treat the External Nodes: This involves addressing the contextual factors themselves. If the “Delayed Train” node is a major source of dysregulation, a practical intervention might be exploring alternative transportation. It’s a direct attempt to lower the rate of a specific stressor.
2. Treat the Internal Nodes: This is about changing the internal system’s response. It could involve “bolstering” the helpful agents—making the “internal psychologist” more skilled and more easily activated—or helping the system learn to down-regulate the unhelpful agents. This feels like a powerful computational metaphor for the work of psychotherapy.

Ultimately, this is just a sketch. But I like how it brings together the internal, agentic self and the probabilistic nature of the external world into one dynamic system. It helps conceptualize a person not as a static collection of symptoms, but as a complex, self-regulating entity constantly adapting to a stream of life events. It’s a compelling way to think.

So, you want to start a technical blog. You’re a developer. You don’t want a clunky, database-driven CMS. You want speed, version control, and the ability to write in your favorite editor using Markdown. You want Jekyll.

But setting up a blog is more than just jekyll new. What happens when posts don’t show up? How do you add downloadable code snippets? And most importantly, what if you want your blog to be private—a personal knowledge base or a pre-launch project accessible only to you and a select few?

This guide covers the entire lifecycle. We’ll go from a blank command line to a fully customized, password-protected Jekyll blog hosted for free. We’ll hit the common roadblocks and solve them, just like in a real-world project.

Part 1: Local Setup - Your Blogging Foundation

First, let’s build the blog on your local machine. This allows you to write, preview, and customize everything before it ever touches the internet.

Step 1: Install the Tools

Jekyll is built with Ruby. You’ll need Ruby and its package manager, RubyGems.

• On macOS (with Homebrew):

  brew install ruby
  

• On Linux (Debian/Ubuntu):

  sudo apt update && sudo apt install ruby-full build-essential zlib1g-dev
  

• On Windows: Download and run the Ruby+DevKit installer from RubyInstaller for Windows. During installation, accept the default to run ridk install on the last step.

Once Ruby is installed, install Jekyll and Bundler (a tool to manage project-specific gems):

gem install jekyll bundler

Step 2: Create and Run Your Blog

Now, let’s create the blog and see it live on your machine.

# 1. Create a new Jekyll site in a folder named "my-personal-blog"
jekyll new my-personal-blog

# 2. Navigate into the new directory
cd my-personal-blog

# 3. Install the specific gems this theme needs
bundle install

# 4. Start the local development server
bundle exec jekyll serve

Open your browser to http://localhost:4000. You should see your new Jekyll blog with the default Minima theme!

Step 3: Your First Blog Post

Posts live in the _posts directory. The filename format is crucial: YYYY-MM-DD-your-title-goes-here.md.

Create a new file: _posts/2025-07-15-my-first-real-post.md

---
layout: post
title: "My First Real Post"
date: 2025-07-15 11:00:00 -0500
categories: getting-started
---

Welcome to my blog! This is content written in **Markdown**.

The section at the top between the `---` lines is called **Front Matter**. It's where you define metadata for the post, like its title and layout.

Save the file. The running server will automatically detect the change and rebuild your site. Refresh your browser, and your new post will appear.

Part 2: Troubleshooting the Inevitable Glitches

Your server is running, but things can go wrong. Here are the most common issues and how to fix them.

• Problem: “My new post isn’t showing up!”
  • Cause: Jekyll, by default, will not publish posts with a date set in the future. If you wrote a post today and dated it for tomorrow, it won’t appear.
  • Solution: For local development, run the server with the --future flag to tell Jekyll to build all posts, regardless of their date.

    bundle exec jekyll serve --future
    

• Problem: “Server won’t start! Address already in use“
  • Cause: You have another Jekyll server (or another process) already running on port 4000. This often happens if you closed a terminal window without stopping the server with Ctrl+C.
  • Solution: Start the server on a different port.

    bundle exec jekyll serve --port 4001
    

• Problem: “Could not locate Gemfile” or “jekyll: command not found“
  • Cause: You are trying to run the command from the wrong directory.
  • Solution: Make sure your terminal is inside your blog’s project folder (e.g., my-personal-blog) before running bundle exec jekyll serve.

Part 3: Customizing Your Content

A blog is more than just a list of posts. Let’s add sections and downloadable files.

Feature 1: Creating “Coding” and “Psychology” Sections

We’ll use Jekyll’s powerful categories feature.

1. Categorize Your Posts: In the front matter of each post, assign a category.
   • For your technical post (_posts/...-wsl2-guide.md):

     ---
     layout: post
     title: "Connecting Your MacBook to WSL2"
     categories: coding
     tags: [wsl2, vscode, development]
     ---
     

   • For a future psychology post:

     ---
     layout: post
     title: "The Psychology of Code Reviews"
     categories: psychology
     ---
     

2. Create Category Pages: Now, create pages that will list all posts from a specific category.
   • Create coding.md in your root directory:

     ---
     layout: page
     title: Coding
     permalink: /coding/
     ---
             
     # Posts about Coding
             
     <ul>
       {% for post in site.categories.coding %}
         <li>
           <h3><a href="{{ post.url | relative_url }}">{{ post.title }}</a></h3>
           <p>{{ post.excerpt }}</p>
         </li>
       {% endfor %}
     </ul>
     

   • Create psychology.md in your root directory with the same content, but replace site.categories.coding with site.categories.psychology.
3. Update Navigation: Add links to your new pages in _config.yml (for the Minima theme). ```yaml header_pages:
   • about.md
   • coding.md
   • psychology.md ```

Feature 2: Adding Downloadable Scripts

Let’s say your WSL2 guide has PowerShell scripts that readers should be able to download.

1. Organize Your Files: The best practice is to store downloadable assets in the assets folder. Create a clear structure.

   my-personal-blog/
   └── assets/
       └── downloads/
           └── wsl2-automation/
               ├── setup-wsl2-ssh.ps1
               ├── update-wsl2-ip.ps1
               └── connect-wsl2.sh
   

2. Link to the Files in Your Post: In your blog post’s Markdown, simply create a standard link pointing to the file.

   ### Download the Automation Scripts
       
   You can download the complete package of scripts to automate this entire process.
       
   *   [Download setup-wsl2-ssh.ps1](/assets/downloads/wsl2-automation/setup-wsl2-ssh.ps1)
   *   [Download update-wsl2-ip.ps1](/assets/downloads/wsl2-automation/update-wsl2-ip.ps1)
   *   [Download connect-wsl2.sh](/assets/downloads/wsl2-automation/connect-wsl2.sh)
   

   Jekyll will automatically serve these files, and clicking the link will trigger a download.

Troubleshooting: What If the Downloads Give a 404 Error?

You’ve set everything up, the links are in your post, but clicking them gives a “404 Not Found” error. This is a common hiccup when first setting up downloadable assets in Jekyll. Here are the most likely culprits, from most to least common:

1. The Build Failed Silently

This is the sneakiest and most common issue. Your downloads aren’t working because your entire Jekyll site isn’t building correctly. An error in a completely different file can prevent Jekyll from generating the _site folder, meaning your assets never get copied to their destination.

• Symptom: The local server crashes or your continuous deployment build fails on Netlify.
• Likely Cause: You have a blog post (especially one about coding, like a Jekyll guide) that contains unescaped Liquid template tags (e.g., ``). Jekyll tries to process this code, leading to an error.

• The Fix: Wrap any example code that uses Liquid syntax in and tags in your Markdown files.

      
  This is an example: {{ site.posts | size }}
      
  

  This tells Jekyll to ignore the code inside, fixing the build error.

2. Filename Mismatch or Case Sensitivity

Your deployment server (like Netlify) runs on Linux, which is case-sensitive. Your local machine (especially Windows) might not be.

• Check for Typos: Ensure the link in your post (/assets/downloads/wsl2-automation/setup-wsl2-ssh.ps1) exactly matches the filename in your Git repository.
• Check for Case: MyScript.ps1 is not the same as myscript.ps1 on the server.

3. How to Test Locally

Before blaming the live server, confirm the files are being served correctly on your local machine.

1. Start the local Jekyll server:

   # In your blog's directory
   bundle exec jekyll serve --port 4001
   

2. Use curl to check the file headers. This command doesn’t download the file, it just checks if the server can find it.

   curl -I http://localhost:4001/assets/downloads/wsl2-automation/setup-wsl2-ssh.ps1
   

3. Look for the HTTP/1.1 200 OK response.
   • ✅ If you get 200 OK, the file is correctly configured in your Jekyll project. The problem is with your live deployment.
   • ❌ If you get 404 Not Found, the problem is in your local project structure. Go back and check steps 1 and 2.

By adding this section, you anticipate a common reader frustration and provide them with a clear, actionable debugging guide, making your post even more authoritative and helpful.

Part 4: The Private Web Host

This is the critical step. We want the blog live on the web, but not public. The source code and the live site must be private.

Warning: Do not use standard GitHub Pages. Even with a private repository, a GitHub Pages site is always public.

Our weapon of choice is Netlify, paired with a private GitHub repository. This gives us free hosting, continuous deployment, and robust password protection.

Step 1: Prepare for Deployment with Git

1. Create a .gitignore file: This file tells Git what not to track. It’s essential for keeping your repository clean. Create a file named .gitignore in your blog’s root with the following content:

   # Jekyll
   _site/
   .sass-cache/
   .jekyll-cache/
   .jekyll-metadata
       
   # Ruby / Bundler
   vendor/bundle/
   .bundle/
       
   # OS files
   .DS_Store
   Thumbs.db
       
   # Logs and temp files
   *.log
   *~
   

2. Create a Private GitHub Repository:
   • Go to GitHub and create a new repository.
   • Give it a name (e.g., private-jekyll-blog).
   • Crucially, set its visibility to “Private”.
3. Push Your Code: In your terminal, from your blog’s directory, run these commands.

   git init
   git add .
   git commit -m "Initial blog setup with content"
   git branch -M main
   # Replace with your actual repo URL
   git remote add origin https://github.com/your-username/private-jekyll-blog.git
   git push -u origin main
   

   Your blog’s source code is now securely stored on GitHub.

Step 2: Deploy and Secure with Netlify

1. Connect Netlify to GitHub:
   • Sign up for a free account at Netlify.com.
   • Click “Add new site” -> “Import an existing project” -> “Deploy with GitHub”.
   • Authorize Netlify to access your repositories and select your new private repo.
2. Configure Build Settings: Netlify will auto-detect that it’s a Jekyll site, but let’s confirm the settings are correct:
   • Build command: bundle exec jekyll build
   • Publish directory: _site
   • Click “Deploy site”. Netlify will now pull your code from GitHub and build your site.
3. Enable Password Protection (Netlify Identity):
   • In your new site’s dashboard on Netlify, go to Site settings > Identity.
   • Click Enable Identity.
   • Scroll down to “Registration” and set the preference to “Invite only”. This ensures only people you explicitly invite can create an account.
   • Go to the Identity tab (in the top navigation) and click “Invite users” to add yourself and anyone else who needs access. They will receive an email to set their password.
4. Add the Login Widget to Your Site: To trigger the login modal, you need to add Netlify’s script.
   • In your Jekyll project, create the file _includes/head.html.
   • Inside this new file, add the following line:

     <script type="text/javascript" src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
     

     This overrides the theme’s default head include to add the script.

5. Commit and Push the Change:

   git add _includes/head.html
   git commit -m "Add Netlify Identity widget"
   git push
   

Netlify will automatically detect the push, rebuild your site, and deploy the new version. Now, when anyone visits your site’s URL, they will be greeted by the Netlify Identity login modal. Only invited and registered users can get past it.

Part 5: Connecting Your Custom Domain (from Cloudflare)

Your site is live on a .netlify.app address, but the final professional touch is using your own domain. This guide shows how to connect a domain managed by Cloudflare to your Netlify site, which is a powerful and common setup.

Prerequisites

1. Domain in Cloudflare: You have successfully purchased your domain name through Cloudflare Registrar.
2. Site on Netlify: Your Jekyll site is deployed on Netlify and has a default URL like your-awesome-site.netlify.app.

Step 1: Get DNS Information from Netlify

1. Log in to your Netlify account and go to the dashboard for your site.
2. Navigate to Site configuration > Domain management.
3. Click Add a domain (or Add custom domain).
4. Enter your custom domain name (e.g., yourdomain.com) and click Verify.
5. Netlify will detect that the domain is already managed elsewhere. Click Add domain.
6. Netlify will now show you the DNS records you need to create. It will be an A record for your root domain (yourdomain.com) pointing to Netlify’s load balancer IP address (e.g., 75.2.60.5) and a CNAME record for the www subdomain pointing to your Netlify site address (your-awesome-site.netlify.app). Keep this page open.

Step 2: Configure DNS Records in Cloudflare

1. Log in to your Cloudflare account and select your domain.
2. On the left sidebar, click on DNS.

3. You may need to delete any existing placeholder A, AAAA, or CNAME records that would conflict with the new ones.

4. Create the A Record (for the root domain):
   • Click Add record.
   • Type: A
   • Name: @ (This represents your root domain).
   • IPv4 address: 75.2.60.5 (Always use the IP address shown in your Netlify dashboard).
   • Proxy status: Leave it as Proxied (orange cloud). This is crucial for enabling Cloudflare’s features.
   • Click Save.
5. Create the CNAME Record (for the ‘www’ subdomain):
   • Click Add record again.
   • Type: CNAME
   • Name: www
   • Target: your-awesome-site.netlify.app (Use your unique Netlify site URL).
   • Proxy status: Leave as Proxied (orange cloud).
   • Click Save.

Your Cloudflare DNS settings should now look like this:

Step 3: Configure SSL/TLS in Cloudflare

This is a critical step to prevent redirect errors.

1. In your Cloudflare dashboard, go to SSL/TLS > Overview.
2. Set your encryption mode to Full (Strict).
   • Why? Netlify provides its own SSL certificate. This setting tells Cloudflare to maintain a secure, encrypted connection all the way to Netlify’s servers.

Step 4: Verification and Finalization

1. Return to your Netlify domain management page. DNS changes can take a few minutes to a few hours to propagate.
2. Netlify will automatically detect the new records and begin provisioning a free Let’s Encrypt SSL certificate for your domain.
3. Once complete, your custom domain will be listed as the primary domain. Your site is now live and secure at https://yourdomain.com.

Conclusion: Your Professional Blogging Workflow

You’ve done it. You now have:

• A fast, modern Jekyll blog running locally.
• A clean, organized content structure with categories and downloads.
• A private Git repository for version control.
• A live, password-protected website with free hosting and automatic deployment.
• A professional custom domain from Cloudflare pointing to your site.

Your workflow is now beautifully simple:

1. Write a new post in Markdown.
2. Preview it locally with bundle exec jekyll serve.
3. Commit and push your changes with git push.

Within minutes, your private blog is updated on your custom domain. You have full control, professional-grade security, and a powerful platform to build your knowledge base. Happy blogging!

Frequently Asked Questions (FAQ)

Q: Is Netlify Identity the only way to password-protect my site?

A: For the free tier, Netlify Identity is the most powerful and recommended method. Netlify’s Pro plans offer a simpler site-wide Basic Password Protection, but Identity provides role-based access and is more flexible.

Q: Why is the Full (Strict) SSL setting in Cloudflare so important?

A: This setting ensures the connection is encrypted end-to-end: from the user’s browser to Cloudflare, and from Cloudflare to Netlify’s servers. If you use Flexible, the connection from Cloudflare to Netlify is unencrypted (HTTP). This often causes a “redirect loop” error, because Netlify automatically tries to redirect HTTP traffic to secure HTTPS, creating a conflict.

Q: Do I have to pay for anything in this setup?

A: The only mandatory cost is purchasing your domain name from Cloudflare. The entire workflow described—private GitHub repository, Jekyll software, Netlify hosting with continuous deployment, and Netlify Identity for a small number of users—is free. Costs would only be incurred if you exceed Netlify’s generous free tier limits for bandwidth or build minutes.

The answer lies in a powerful combination: Windows Subsystem for Linux (WSL2), SSH, and VS Code’s Remote Development extension.

This guide will walk you through the entire process, from setting up WSL2 on your Windows machine to seamlessly connecting and coding from your MacBook. We’ll cover the manual setup so you understand the mechanics, and then show you how to automate the process to handle common issues like changing IP addresses.

The Big Picture: How Does This Work?

Before we dive in, let’s understand the architecture. Your MacBook can’t directly “see” the Linux instance running inside WSL2, as it lives in its own virtual network on your Windows machine. We need to create a bridge.

1. WSL2 Ubuntu: Runs a full Linux environment with its own private IP address. We’ll install an SSH server here.
2. Windows 11 Pro: Acts as the host. We will configure it to forward traffic from one of its network ports to the SSH port on the WSL2 instance.
3. Your MacBook: Will connect via SSH to your Windows machine’s IP address on the special forwarded port, which Windows will then transparently route to WSL2.

Part 1: Setting Up the Host (Windows 11 Pro)

First, we need to get WSL2 and our Ubuntu environment ready to accept connections.

Step 1: Install WSL2 and Ubuntu

If you haven’t already, installing WSL2 and the default Ubuntu distribution is a one-line command. Open PowerShell as an Administrator and run:

wsl --install -d Ubuntu

This command will enable the necessary Windows features (Virtual Machine Platform, Windows Subsystem for Linux), download the latest Linux kernel, and install the Ubuntu distribution. Restart your computer if prompted.

Step 2: Configure the Ubuntu SSH Server

Once installed, launch your new Ubuntu environment from the Start Menu. Now, let’s set up the SSH server inside it.

1. Update and Install OpenSSH Server: It’s always good practice to update your package lists before installing new software.

   # Inside the Ubuntu WSL2 terminal
   sudo apt update
   sudo apt install openssh-server
   

2. Start and Enable the SSH Service: We need to start the SSH service and ensure it launches automatically every time WSL2 starts.

   sudo service ssh start
      
   # Optional but recommended: enable the service to start on boot
   sudo systemctl enable ssh
   

   You can verify it’s running with sudo service ssh status.

Step 3: Create the Network Bridge (Port Forwarding)

This is the most critical step. We need to tell Windows to forward traffic to our WSL2 instance.

1. Find the WSL2 IP Address: Your WSL2 instance has a dynamic IP address that can change each time it restarts. Find the current one by running this command inside the Ubuntu terminal:

   # This will print the IP address, e.g., 172.28.17.73
   hostname -I
   

   Take note of this IP address. For our example, we’ll use 172.28.17.73.

2. Set Up Port Forwarding in PowerShell: Exit the Ubuntu terminal and go back to a PowerShell window running as Administrator. We will forward port 2222 on Windows to port 22 (the default SSH port) on our WSL2 instance.

   Note: Replace 172.28.17.73 with the IP address you found in the previous step.

   # In an Administrator PowerShell
   netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=22 connectaddress=172.28.17.73
   

3. Create a Firewall Rule: Windows Firewall will block the new port by default. Let’s create a rule to allow incoming traffic on port 2222.

   # In the same Administrator PowerShell
   New-NetFirewallRule -DisplayName "WSL2 SSH Bridge" -Direction Inbound -LocalPort 2222 -Protocol TCP -Action Allow
   

Your Windows host is now ready!

Part 2: Connecting From Your MacBook

Now for the fun part. Let’s connect from your MacBook using VS Code.

Step 1: Find Your Windows IP Address

You need the local network IP of your Windows machine. On the Windows PC, open a regular Command Prompt or PowerShell and run:

ipconfig

Look for the “IPv4 Address” under your active Wi-Fi or Ethernet adapter. It will likely look something like 192.168.0.113.

Step 2: Connect with VS Code Remote-SSH

On your MacBook, make sure you have the Remote Development extension pack installed in VS Code.

1. Open VS Code and press Cmd+Shift+P to open the Command Palette.
2. Type Remote-SSH: Add New SSH Host... and press Enter.

3. Enter the connection command using your WSL Ubuntu username, your Windows IP, and the forwarded port (2222).

   # Format: ssh <wsl-username>@<windows-ip> -p 2222
   # Example:
   ssh jboldsenryan@192.168.0.113 -p 2222
   

4. Choose the first option to update your SSH config file (~/.ssh/config).
5. Now, connect! Press Cmd+Shift+P again and select Remote-SSH: Connect to Host....
6. Choose the host you just added (e.g., 192.168.0.113).
7. The first time you connect, you’ll be asked to confirm the server’s fingerprint (type yes) and then enter the password for your Ubuntu user. VS Code will then install its server components in WSL2.

That’s it! Your VS Code window is now running remotely inside WSL2. The integrated terminal is a full Ubuntu shell, and any files you open are on the Linux filesystem.

Your Daily Workflow & Troubleshooting

The initial setup is done once. Here’s what your daily use looks like.

Daily Workflow:

1. On Windows: Make sure your WSL2 instance is running. You can start it with wsl -d Ubuntu.
2. On MacBook: Open VS Code, go to the Remote Explorer tab, and click the connect icon next to your saved host.

Troubleshooting Common Issues

1. Connection Refused? This usually means the SSH server isn’t running in WSL2 or WSL2 itself is shut down.

• On Windows: Check WSL status with wsl --list --verbose.
• In WSL2: Start the SSH server with sudo service ssh start.

2. The WSL IP Address Changed! This is the most common problem. After a reboot of your Windows PC, WSL2 will likely get a new IP address, breaking your port forwarding rule.

• Solution:
  1. Get the new WSL2 IP with hostname -I.
  2. On Windows (in an Admin PowerShell), remove the old rule and add the new one:

     # Get the new IP first! Let's say it's now 172.28.20.55
     netsh interface portproxy delete v4tov4 listenport=2222 listenaddress=0.0.0.0
     netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=22 connectaddress=172.28.20.55
     

Level Up: Automate the IP Problem

Manually updating the IP is tedious. I’ve created a set of PowerShell scripts to automate this entire process. The main script, setup-wsl2-ssh.ps1, can automatically detect the WSL2 IP and update the port forwarding rule for you.

If you have these scripts, you can fix a changed IP by simply running this on Windows:

# Run PowerShell as Administrator
.\setup-wsl2-ssh.ps1

This single command finds the current IP, sets the port forward, and configures the firewall, making maintenance a breeze!

📥 Download the Automation Scripts

I’ve created practical scripts to automate this entire process. You can download them directly:

Essential Scripts

• setup-wsl2-ssh.ps1 - Complete automated setup and IP management
• update-wsl2-ip.ps1 - Quick IP update when WSL2 restarts
• connect-wsl2.sh - Simple connection script for Mac/Linux

Quick Start with Scripts

1. Download and run the main setup script:

   # In PowerShell as Administrator (Windows)
   .\setup-wsl2-ssh.ps1
   

2. When WSL2 IP changes (after restarts):

   # Quick IP update (Windows)
   .\update-wsl2-ip.ps1
   

3. Connect from Mac/Linux:

   # Make executable and run (Mac/Linux)
   chmod +x connect-wsl2.sh
   ./connect-wsl2.sh
   

The scripts handle error checking, provide colored output, and can recover from most common issues automatically.

Conclusion

You now have a professional-grade, cross-platform development environment. You can leverage the raw power of your Windows machine to run Linux containers, build heavy projects, and run backend services, all while enjoying the fluid user experience of your MacBook Air. By understanding the manual steps and leveraging automation for maintenance, you’ve created a workflow that is both powerful and sustainable.

Happy coding! 🚀

Gist: This post is a musing on whether the ‘factor structure’ we find for psychological constructs like emotion is just an artifact of the temporal scale we use to measure them. I’m using the analogy of a Japanese Maple tree: from a distance, it’s a single “purple” factor, but up close, it resolves into many distinct color factors. The idea is that our measurement intervals—moment, day, month—are just different temporal distances, each revealing a different, but equally ‘true’, view of a person’s inner world. It makes me cautious about mixing scales.

I’ve been turning over an idea that I can’t seem to shake. It’s about measurement, and how the timescale we choose to measure with might fundamentally change the psychological phenomena we think we’re observing. It feels almost obvious when I write it down, but the implications seem to ripple out in interesting ways.

The core of it is this: as our measurement interval gets longer—moving from a moment, to a day, to a week—what we’re measuring seems to shift from something discrete and flickering to something more stable and “trait-like.” I wonder if this means that the number of “factors” we find in our data isn’t just a property of the person, but an artifact of the temporal lens we’re using to look at them.

The Japanese Maple from a Distance

I keep coming back to a visual analogy. Imagine looking at a Japanese Maple tree from 200 yards away. From that distance, the canopy might resolve into a single, dominant color. If I were to “factor analyze” the colors of that tree from afar, I’d likely find a one-factor solution: “Purple.” All the colors would load heavily onto this single dimension. It’s a true representation of the tree from that distance.

But what happens if I walk 100 yards closer? Now, my perception has a higher resolution. I can distinguish the bright orange leaves on the sunny side from the deeper violet hues in the shade. My one-factor “Purple” model breaks down. I now have at least two factors: “Orange” and “Violet.”

If I walk right up to the tree and stand beneath its branches, the complexity multiplies. I can see that some leaves are a brilliant, almost-neon red. Others have yellow edges. Some of the “violet” leaves I saw from a distance are actually a deep, subtle blue mixed with purple. Suddenly, my two-factor model is insufficient. I might now need five factors to adequately describe the colors: Red, Orange, Yellow, Blue, and Purple.

None of these factor solutions are “wrong.” They are all accurate representations of the tree at different observational distances. The number of factors, the “structure” of the color, is a function of my proximity.

The Distant Self and the Momentary Self

This is where the idea gets interesting for me when thinking about affect. What if time is just another kind of distance?

When we ask someone to fill out a questionnaire about their “past month,” we are, in a sense, asking them to view their “distant self.” From that temporal distance, the fine-grained details of their emotional life may blur. The momentary flashes of pride, joy, and excitement that occurred over thousands of moments might blend together in memory’s calculus. When they reflect, they may only be able to access the broad strokes, the overarching impression. It wouldn’t surprise me if their experience, when measured this way, resolves into just two dominant “colors”: a “Positive Affect” factor and a “Negative Affect” factor.

But what if we measure their “daily self”? Here, we’re a bit closer. The resolution is higher. They might be able to distinguish “anxious” feelings from general “sadness,” or “contentment” from “excitement.” More factors might emerge because the temporal distance is shorter, and less mental averaging is required.

And then there’s the “momentary self,” the target of things like Ecological Momentary Assessment (EMA). This is our attempt to stand right under the branches of the tree. Here, we might expect to see the most complexity, the greatest number of distinct affective “factors.” Yet, even here, I have my doubts. Is EMA truly measuring a single, instantaneous emotional state? Or is it asking someone to pause and perform a rapid “mental calculus” of the last 60 seconds? Even our most granular measurements might still be a slight time-average, a small bundle of experiences rather than a single, discrete emotional leaf.

Some Wrinkles in the Analogy

This line of thinking makes me cautious. If the factor structure of affect is dependent on the temporal scale of measurement, then what does it mean to mix those scales? It seems akin to trying to run a single analysis on a photograph of the whole tree from 200 yards away and a microscopic image of a single leaf’s cell structure. The data are measuring phenomena at such fundamentally different levels of organization that asking how they “group” together feels like a category error.

It also makes me question what a “factor” even is in this context. Perhaps, at a given timescale, a factor doesn’t represent some deep, underlying latent entity. Maybe it simply tells us which discrete emotional states are most likely to be bundled together or co-occur within that specific temporal window. The “Positive Affect” factor in a weekly survey might not be a singular entity, but simply a name we give to the observation that moments of joy, interest, and contentment tended to happen in close succession during that period.

I don’t have an answer here. It’s just a thought experiment. But it does seem that the “truth” of our inner world’s structure might not be a single, static architecture. Perhaps it’s more like that Japanese Maple—a different, but equally valid, truth revealed at every possible distance from which we choose to look.