AndyJarrett.com

Reclaiming Space on macOS from Docker by Pruning Docker.raw

Andy Jarrett — Thu, 29 Aug 2024 22:02:00 +0000

^{Photo by Nathan Cima on Unsplash}

Docker on macOS stores its container data in a virtual disk file called Docker.raw. This file is used by Docker's internal virtual machine (VM) and can grow dynamically as more containers and images are created. Over time, even when containers are deleted, Docker.raw can take up substantial disk space.

I recently encountered this issue, where my Docker.raw file showed a size of 60G:

$ ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

However, the actual disk usage was 31G:

$ du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

The discrepancy occurs because Docker.raw is a sparse file. While it can potentially use 60G, it only occupies 31G of actual disk space.

To reclaim space, you can clean up unused data with:

$ docker system prune

Note: Space is only freed when images are deleted. Space inside running containers is not automatically reclaimed. To trigger space reclamation, run:

$ docker run --privileged --pid=host docker/desktop-reclaim-space

For more details, refer to the official Docker documentation: Docker Desktop FAQs for macOS.

Bluesky now has over 10 million users, and I was #56,137!

Andy Jarrett — Mon, 16 Sep 2024 17:01:00 +0000

^{Photo by Adam Birkett on Unsplash}

Bluesky now has over 10 million users, and I was #56137!

Understanding Variable Scoping Differences Between Lucee 5 and Lucee 6

Andy Jarrett — Wed, 09 Oct 2024 07:28:00 +0000

^{Photo by Brina Blum on Unsplash}

From a conversation on the Working Code Podcast Discord channel I came across a change between Lucee 5 to Lucee 6, and how variables are scoped and handled, specifically when/if using var in a .cfm template. This post is just the sample code I used to do some digging on how the scoping differences between the two versions using a simple test cases to show the different outcomes

Test Scenario

Here are my test files, var.cfm and varinclude.cfm.

`var.cfm` (main template):

<cfscript>
  var a = "a";
  b = "b";
  local.c = "c";

  dump(a); // Output: "a"
  dump(b); // Output: "b"
  dump(c); // Output: "c"
  dump(local.c); // Output: "c"

  cfinclude(template="varinclude.cfm");
</cfscript>

`varinclude.cfm` (included template):

<cfscript>
  dump(a); // Output: "a"
  dump(b); // Output: "b"
  dump(c); // Output: "c"
  dump(local.c); // Output: "c"
</cfscript>

This setup works well on Lucee 5, where:

The var keyword is used to declare variables with function-local scope, even outside functions.
The variable b is implicitly scoped to the current page.
The local scope is explicitly used for c.

Results on Lucee 5

On Lucee 5, the following outputs occur:

dump(a); outputs "a".
dump(b); outputs "b".
dump(c); outputs "c".
dump(local.c); outputs "c".

The included template (varinclude.cfm) inherits these variables, and everything behaves as expected. This is because, in Lucee 5, var declarations work even outside of functions.

Behaviour in Lucee 6

When upgrading to Lucee 6, however, some changes in scoping rules cause issues:

Using var outside a function:
```
<cfscript>
  var a = "a"; // This line fails with "Can't invoke key A, Local Scope can only be invoked inside a Function"
</cfscript>
```
In Lucee 6, the var keyword is now restricted to function scopes, and attempting to use it outside a function will result in an error. This is a notable shift from Lucee 5.
Accessing c without scoping:
```
<cfscript>
  dump(c); // This line fails with "variable [C] doesn't exist"
</cfscript>
```
Lucee 6 enforces stricter scoping rules. Without explicitly declaring c in a shared scope (such as local.c), it's no longer accessible in the same way as in Lucee 5.

TL;DR

When migrating from Lucee 5 to Lucee 6, developers need to be aware of the stricter scoping rules. var is now restricted to function scope in Lucee 6. Attempting to use it outside of a function will result in an error.

Connection pools in Node.js with MariaDB

Andy Jarrett — Tue, 19 Nov 2024 07:30:00 +0000

^{Photo by Alec Weir on Unsplash}

TL;DR:

Find the GitHub project here: github.com/andyj/mariadb-connection-pool

Why Use a Connection Pool?

Database connection pooling critical for your web applications. Without a pool, every database query spins up a new connection which startes eating up your resources! A connection pool keeps a stash of open connections ready to go, slashing overhead and boosting performance.

This also gave me an excuse to go back over some old code of mine and start putting in console methods for debugging that I've covered recently

Benefits of Connection Pooling

Reduced latency: Reusing connections cuts out the time spent establishing new ones.
Better resource management: Caps the number of simultaneous connections to keep your database happy.
Improved scalability: Handle more users without breaking a sweat.

Setting Up a MariaDB Connection Pool in Node.js

First things first, you'll need the mariadb package. Install it using:

npm install mariadb dotenv

Here's how to set up the pool:

Connection Pool Configuration


// db.js
require('dotenv').config(); // Load environment variables

const mariadb = require('mariadb');

const pool = mariadb.createPool({
  host: process.env.DB_HOST,         // Use DB_HOST environment variable from .env
  user: process.env.DB_USER,         // Use DB_USER environment variable from .env
  password: process.env.DB_PASSWORD, // Use DB_PASSWORD environment variable from .env
  database: process.env.DB_NAME,     // Use DB_NAME environment variable from .env
  port: process.env.DB_PORT,         // Use DB_PORT environment variable from .env
  connectionLimit: 10                // Maximum number of connections in the pool
});

module.exports = pool;

This creates a pool with up to 10 connections. Feel free to tweak the connectionLimit based on what your app needs.

Using the Pool in Your Application

Let's look at how to use the connection pool in an Express route. We'll sprinkle in some advanced console methods to make debugging a breeze.


const express = require('express');
const pool = require('./db'); // Import the pool
const app = express();

app.get('/data', async (req, res) => {
  console.group('Database Query');
  console.time('Query Time');

  let conn;
  try {
    conn = await pool.getConnection();
    console.assert(conn, 'Failed to obtain a database connection');

    const rows = await conn.query('SELECT current_timestamp()');
    console.table(rows);

    res.json(rows);
  } catch (err) {
    console.error('Error executing query');
    console.trace(err);
    res.status(500).send('Database query error');
  } finally {
    if (conn) conn.release(); // Release the connection back to the pool
    console.timeEnd('Query Time');
    console.groupEnd();
  }
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

Here's what those console methods are doing for you:

console.group() and console.groupEnd(): Groups related log messages, making your console output neater.
console.time() and console.timeEnd(): Measures how long your query takes, helping you spot performance issues.
console.assert(): Checks if you got a connection. If not, it logs an error message.
console.table(): Displays your query results in a nice table format in the console.
console.trace(): Prints a stack trace from the point where it's called, super handy for debugging errors.

By using these methods, you get a clearer picture of what's going on under the hood, which is clutch when you're trying to debug or optimize your app.

Best Practices

Keep an eye on pool usage to tweak connectionLimit as needed.
Use connection timeouts to handle idle or long-running queries.
Implement error handling to gracefully manage database hiccups.
Leverage advanced console methods to make debugging smoother.

Conclusion

The mariadb package makes it easy to manage database connections efficiently.

And if you’re using managed database services like AWS RDS for MariaDB or Azure Database for MariaDB, there are additional settings you should consider tweaking for optimal performance:

Connection Pool Limits: AWS and Azure instances often come with predefined limits on concurrent connections based on the instance size. Make sure your connectionLimit aligns with these constraints to avoid hitting caps that could cause connection errors.
Timeouts and Idle Connections: Both AWS and Azure charge for resources tied to active connections. Use settings like idleTimeoutMillis to close unused connections after a certain period. This helps in reducing costs and freeing up database resources.
Max Allowed Packet: Tweak this for handling large queries or data sets, especially if your app processes bulk data.
Monitoring and Scaling: Both platforms offer native monitoring tools (e.g., Amazon CloudWatch or Azure Monitor) to keep an eye on metrics like CPU usage, connections, and query performance. Use these insights to adjust your pool size dynamically.

How to Run SVR.JS with Docker Compose

Andy Jarrett — Tue, 26 Nov 2024 22:30:00 +0000

^{Photo by Florian Olivo on Unsplash}

TL;DR: Project code here: github.com/andyj/svrjs-with-docker

Why SVR.JS?

SVR.JS is a lightweight and efficient web server designed to serve static files effortlessly. It's great for scenarios where you need a quick and reliable solution to host static content without the overhead of traditional web servers.

By combining SVR.JS with Docker, you can eliminate installation dependencies and simplify deployment, making it an ideal choice for developers, testers, and small-scale projects.

How to Set It Up

Step 1: Docker Compose Configuration

version: '3.9'
services:
  svrjs:
    image: svrjs/svrjs:lts
    container_name: svrjs-server
    platform: linux/amd64
    ports:
      - "8080:80"  # Map port 8080 on host to port 80 in the container
    volumes:
      - ./www:/var/www/svrjs  # Mount the local `www` directory as the web root
      - ./svrjs-config.json:/etc/svrjs-config.json  # Mount custom config
    restart: always

This docker-compose.yml file defines the SVR.JS service. It maps port 8080 on the host to port 80 in the container and sets up volumes for the web root and configuration file.

Step 2: Configuration File

{
  "port": 80,
  "wwwroot": "/var/www/svrjs",
  "logging": {
    "enabled": true,
    "level": "info"
  }
}

Save this as svrjs-config.json. It configures SVR.JS to serve files from the specified directory and enables basic logging.

Step 3: Directory Structure

Create the following directory structure for your project:

svrjs-with-docker
├── README.md
├── docker-compose.yml
├── svrjs-config.json
└── www
    ├── index.html
    └── style.css

The www folder will hold your static files, such as index.html and style.css.

Step 4: Example HTML File

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>SVR.JS Test</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <h1>Welcome to SVR.JS</h1>
  <p>This static file is served by SVR.JS.</p>
</body>
</html>

Save this as index.html inside the www directory.

Step 5: Running the Server

In the root directory of your project, run the following command:

docker-compose up

After the container starts, visit http://localhost:8080 to see your static site in action.

Conclusion

SVR.JS, combined with Docker, provides a powerful and hassle-free way to serve static content. This setup is highly portable and easy to replicate across different environments, making it a valuable tool for developers of all levels.

Using SVR.js to Run Server-Side JavaScript

Andy Jarrett — Fri, 29 Nov 2024 22:30:00 +0000

^{Photo by NASA on Unsplash}

TL;DR: Updated project code here: github.com/andyj/svrjs-with-docker

How to Use SVR.js to Run Server-Side JavaScript

Building on the Basics

In my previous post, How to Run SVR.js with Docker Compose, I introduced a simple way to set up SVR.js for serving static files using Docker Compose. Since then, I’ve expanded the project to explore server-side capabilities of SVR.js.

To accommodate this, the project structure has evolved on GitHub, and now includes multiple folders for different setups. Specifically, the new 2.serverside-javascript-svrjs folder demonstrates how to run server-side JavaScript. Let’s dive in!

Updated Project Structure

svrjs-with-docker/
├── 1. how-to-run-svrjs-with-docker-compose
│   ├── README.md
│   ├── docker-compose.yml
│   ├── svrjs-config.json
│   └── www
│       ├── index.html
│       └── style.css
├── 2.serverside-javascript-svrjs
│   ├── README.md
│   ├── docker-compose.yml
│   ├── server
│   │   └── time.js
│   ├── svrjs-config.json
│   └── www
│       ├── index.html
│       └── style.css
├── LICENSE
└── README.md

Step 1: The Configuration File

The new svrjs-config.json enables server-side JavaScript by defining a route that maps to a server-side script:

{
"port": 80,
"wwwroot": "/var/www/svrjs",
"logging": {
  "enabled": true,
  "level": "info"
},
"routes": {
  "/time": "../server/time.js"
}
}

Step 2: Writing Server-Side Logic

Create the time.js file in the server folder:

module.exports = (req, res) => {
  const currentTime = new Date().toLocaleString();
  res.setHeader('Content-Type', 'application/json');
  res.end(JSON.stringify({ message: "Hello, World!", time: currentTime }));
};

Step 3: Updated Docker Compose Configuration

Here’s the docker-compose.yml file for this setup:

services:
svrjs:
  image: svrjs/svrjs:lts
  container_name: svrjs-server
  platform: linux/amd64
  ports:
    - "8282:80"
  volumes:
    - ./www:/var/www/svrjs
    - ./server:/var/server
    - ./svrjs-config.json:/etc/svrjs-config.json
  restart: always

Step 4: Running the Server

Run the following command from the 2.serverside-javascript-svrjs directory:

docker compose up

Once the container is running, navigate to:

Static Files: http://localhost:8282
Server-Side Endpoint: http://localhost:8282/time

Testing the Endpoint

Visiting /time in your browser or via a tool like curl will return a JSON response similar to:

{
"message": "Hello, World!",
"time": "28/11/2024, 15:00:00"
}

Conclusion

With minimal effort, SVR.js transforms from a static file server into a lightweight tool for handling server-side JavaScript. By leveraging Docker for deployment, this setup is both portable and scalable.

What server-side features will you build next with SVR.js? Let me know in the comments or contribute to the project on GitHub!

Why Updating Alpine.js State with Direct Reassignment Fails (and How to Fix It)

Andy Jarrett — Fri, 10 Jan 2025 17:30:00 +0000

^{Photo by Trevor Wilson on Unsplash}

Why Updating Alpine.js State with Direct Reassignment Fails (and How to Fix It)

Reactivity is amazing, but when it fails its frustrating. And with that a stupid issue hit me recently because of direct reassignment of a variable that I did. In my defence I was reassigning the property this.formFields after fetching JSON. So, this blog post is here to remind me to check the obvious first.

I'm going to use dummyjson.com to get some data to explain. Imagine you’re building a product page, and you want to fetch product details from an API and update your form fields dynamically. Here’s a simplified HTML:

<div x-data="productForm()" x-init="fetchProduct()">
  <div>
    <p>Title: <span x-text="formFields.title"></span></p>
    <p>Price: £<span x-text="formFields.price"></span></p>
    <p>Rating: <span x-text="formFields.rating"></span></p>
    <p>Stock: <span x-text="formFields.stock"></span></p>
  </div>
</div>

And Alpine.js component

function productForm() {
  return {
    formFields: {
      title: '',
      price: 0,
      rating: 0,
      stock: 0
    },
    async fetchProduct() {
      const response = await fetch('https://dummyjson.com/products/1');
      const json = await response.json();

      // Replace formFields but rebind to Alpine
      this.formFields = json;
    }
  };
}

The API response:

{
  "id": 1,
  "title": "Essence Mascara Lash Princess",
  "price": 9.99,
  "rating": 4.94,
  "stock": 5
}

The result: The values have not changed, and still showing the default values.

Why This Fails

When you reassign this.formFields to the new json object, Alpine.js no longer tracks changes to formFields. This is because Alpine’s reactivity system is based on proxies, and direct reassignment breaks the connection to the original proxy object.

In essence, Alpine.js is still observing the old formFields object, but you’ve replaced it with a completely new object.

The Fix

Instead of directly reassigning the object, update individual properties of formFields so that Alpine’s reactivity remains intact:

async fetchProduct() {
  const response = await fetch('https://dummyjson.com/products/1');
  const json = await response.json();

  // Update individual properties
  this.formFields.title = json.title;
  this.formFields.price = json.price;
  this.formFields.rating = json.rating;
  this.formFields.stock = json.stock;
}

By updating the properties one by one, Alpine.js can detect and respond to the changes properly.

A Cleaner Approach

If you’re working with multiple properties, you can use Object.assign to merge the new data into the existing formFields object:

async fetchProduct() {
  const response = await fetch('https://dummyjson.com/products/1');
  const json = await response.json();

  // Merge new data into formFields
  Object.assign(this.formFields, {
    title: json.title,
    price: json.price,
    rating: json.rating,
    stock: json.stock
  });

  // Or you could do this
  // Object.assign(this.formFields, json);
  // though if the json object contains additional properties that you don’t want in this.formFields, they will also be added.
}

This approach avoids keeps the code clean and maintainable.

Direct reassignment of an object in Alpine.js may seem intuitive, but it can break the reactivity system. By updating individual properties or merging data using Object.assign, you can ensure your state remains reactive and your UI updates as expected. This small adjustment can save you significant debugging time and (for me) frustration in Alpine.js projects.

Fixing Alpine.js Template Rendering Issues When Your Second Tag Isn't Showing

Andy Jarrett — Mon, 13 Jan 2025 23:28:00 +0000

^{Photo by Ales Krivec on Unsplash}

When working with Alpine.js templates, I ran into an issue where only the first child element inside a <template> tag is rendered, leaving subsequent elements mysteriously absent.

Understanding the Problem

Consider the following code:

<template x-if="products.product_id">
  <a :href="`/products/edit/${products.item_short_ref}/${products.item_code}`" class="px-2">
    Edit
  </a>
  <a :href="`/products/delete/${products.item_short_ref}/${products.item_code}`" class="px-2">
    Delete
  </a>
</template>

You might expect both <a> tags to render when the x-if condition is true. However, Alpine.js requires a single root element inside the <template> tag. If there are multiple sibling elements, only the first one will appear.

The Solution

To resolve this, wrap the content inside the <template> in a parent container, such as a <div> or <span>. Here’s the corrected code:

<template x-if="products.product_id">
  <span class="flex">
    <a :href="`/products/edit/${products.item_short_ref}/${products.item_code}`" class="px-2">
      Edit
    </a>
    <a :href="`/products/delete/${products.item_short_ref}/${products.item_code}`" class="px-2">
      Delete
    </a>
  </span>
</template>

The <span> acts as the single root node required by Alpine.js, allowing both <a> tags to render properly.

A Demo of the Issue and Solution

Here’s a simplified demonstration to illustrate the problem:

Code with Issue

<div x-data="{ open: false }">
  <button x-on:click="open = !open">Toggle 1 (shows one link only)</button>
  <template x-if="open">
    <a href="#">Link 1</a>
    <a href="#">Link 2</a>
  </template>
</div>

In this case, only "Link 1" will appear when you click the button.

Corrected Code

<div x-data="{ open: false }">
  <button x-on:click="open = !open">Toggle 2 (shows both links)</button>
  <template x-if="open">
    <div>
      <a href="#">Link 1</a>
      <a href="#">Link 2</a>
    </div>
  </template>
</div>

Now, both links will render correctly when the button is toggled.

Provisioning OneDrive for Microsoft365 Users Before First Login

Andy Jarrett — Tue, 04 Feb 2025 00:00:00 +0000

^{Photo by appshunter.io on Unsplash}

Why Pre-Provision OneDrive?

By default, OneDrive accounts for Microsoft 365 users are not created until they sign in for the first time. However, if you’re planning a migration from another cloud provider, such as Google Drive, you need to provision these OneDrive accounts in advance to ensure a smooth transition as we found out.

Below is a rough guide and SharePoint PowerShell script to automate the process.

Pre-Requisites

Before running the script, you need to ensure that PowerShell allows execution of scripts. Run the following command in PowerShell (this cannot be part of the script itself):

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted

This enables execution for the session without changing system-wide policies.

The PowerShell Script

Save the following script as provision_onedrive.ps1. It connects to your SharePoint Online admin centre and checks whether OneDrive is provisioned for each user. If not, it requests its creation.

# Define the list of user emails
$UserEmails = @(
"firstname1.lastname1@example.com",
"firstname2.lastname2@example.com",
"firstname3.lastname3@example.com"
)

# Define SharePoint Online Admin URL (replace with your actual tenant)
$TenantAdminURL = "https://[your-tenant]-admin.sharepoint.com"

# Connect to SharePoint Online (if not already connected)
Try {
    Connect-SPOService -Url $TenantAdminURL -ErrorAction Stop
    Write-Host "Connected to SharePoint Online successfully."
} Catch {
    Write-Host "Error connecting to SharePoint Online: $_" -ForegroundColor Red
    Exit
}

# Loop through each user email
foreach ($email in $UserEmails) {
    Write-Host "Checking OneDrive status for $email..."

    # Check if OneDrive is already provisioned
    $site = Get-SPOSite -IncludePersonalSite $true -Limit all | Where-Object { $_.Owner -eq $email } -ErrorAction SilentlyContinue

    if ($site) {
        Write-Host "OneDrive already exists for $email" -ForegroundColor Green
    } else {
        Write-Host "Provisioning OneDrive for $email..." -ForegroundColor Yellow
        Request-SPOPersonalSite -UserEmails $email
        Write-Host "OneDrive provisioning requested for $email" -ForegroundColor Cyan
    }
}

Write-Host "OneDrive provisioning script completed." -ForegroundColor Magenta

How It Works

The script defines a list of user emails.
It connects to the SharePoint Online admin centre.
It checks if OneDrive is already provisioned for each user.
If OneDrive is missing, it requests its creation.

Running the Script

To execute the script, open PowerShell as an administrator and run:

.\provision_onedrive.ps1

You'll see output indicating whether each user's OneDrive already exists or has been requested for provisioning.

Final Thoughts

Pre-provisioning OneDrive ensures a seamless migration for users switching from Google Drive or other storage solutions. This automation removes delays and guarantees that user drives are ready before they even log in.

Let me know in the comments if you have any questions or if you’d like additional automation enhancements!

Learning Python Offline with a PWA

Andy Jarrett — Sat, 17 May 2025 07:01:00 +0000

^{Photo by Rubaitul Azad on Unsplash}

TL;DR: Explore the offline Python PWA on GitHub: github.com/andyj/learn_python_offline_pwa and View The App Here

Learning Python Offline with a PWA

Why AI, Why Offline?

I’ve always wanted to get back to basics and truly understand Python’s core concepts without being tethered to a network. When my family and I started planning a trip I realised I’d be offline for a bit and I saw an opportunity. Why not build a Progressive Web App (PWA) that teaches Python fundamentals entirely client-side, even when you’ve got zero signal?

Building Skulpt Locally

Rather than pulling Skulpt from a CDN, I cloned the public repositories, ran the build process locally (with a quick nvm switch to Node 16 to avoid OpenSSL issues), and bundled the minified skulpt.min.js and skulpt-stdlib.js into dist/. That way the entire runtime ships with the app—no internet required.

Technical Highlights

Offline-first: A service worker precaches every HTML, CSS, JS and Skulpt asset.
Single page layout: Collapsible sidebar for navigation; main pane for lessons, code editors and quizzes.
Interactive code: Editable Python snippets powered by Skulpt, with real-time output.
Progress tracking: Quiz results saved in localStorage, so you can pick up where you left off.
Lightweight styling: Mobile-first, plain CSS, no frameworks, so it’s lightning fast and fully functional offline.

Try It Yourself

You can explore the code, clone the repo, or file issues over on GitHub:

🔗 https://github.com/andyj/learn_python_offline_pwa

Conclusion

Whether you’re a digital nomad, a commuter or just someone who likes to tinker offline, this PWA lets you learn Python wherever you are. Give it a spin on your device, just add it to your home screen and you’re good to go.

AndyJarrett.com

Reclaiming Space on macOS from Docker by Pruning Docker.raw

Bluesky now has over 10 million users, and I was #56,137!

Understanding Variable Scoping Differences Between Lucee 5 and Lucee 6

Test Scenario

var.cfm (main template):

varinclude.cfm (included template):

Results on Lucee 5

Behaviour in Lucee 6

TL;DR

Connection pools in Node.js with MariaDB

Why Use a Connection Pool?

Benefits of Connection Pooling

Setting Up a MariaDB Connection Pool in Node.js

Connection Pool Configuration

Using the Pool in Your Application

Best Practices

Conclusion

How to Run SVR.JS with Docker Compose

Why SVR.JS?

How to Set It Up

Step 1: Docker Compose Configuration

Step 2: Configuration File

Step 3: Directory Structure

Step 4: Example HTML File

Step 5: Running the Server

Conclusion

Using SVR.js to Run Server-Side JavaScript

How to Use SVR.js to Run Server-Side JavaScript

Building on the Basics

Updated Project Structure

Step 1: The Configuration File

Step 2: Writing Server-Side Logic

Step 3: Updated Docker Compose Configuration

Step 4: Running the Server

Testing the Endpoint

Conclusion

Why Updating Alpine.js State with Direct Reassignment Fails (and How to Fix It)

Why Updating Alpine.js State with Direct Reassignment Fails (and How to Fix It)

Why This Fails

The Fix

A Cleaner Approach

Fixing Alpine.js Template Rendering Issues When Your Second Tag Isn't Showing

Understanding the Problem

The Solution

A Demo of the Issue and Solution

Code with Issue

Corrected Code

Provisioning OneDrive for Microsoft365 Users Before First Login

Why Pre-Provision OneDrive?

Pre-Requisites

The PowerShell Script

How It Works

Running the Script

Final Thoughts

Learning Python Offline with a PWA

Learning Python Offline with a PWA

Why AI, Why Offline?

Building Skulpt Locally

Technical Highlights

Try It Yourself

Conclusion

`var.cfm` (main template):

`varinclude.cfm` (included template):