Forem: Mike Rispoli

Land A $195K Job With AI

Mike Rispoli — Mon, 26 Jan 2026 15:52:11 +0000

We applied for a $195K Treasury job using AI and got wildly different results.

When Sam Corcos (@samcorcos) posted a government IT specialist position requiring applicants to write a 10 page Great Gatsby analysis using AI, translate it into Spanish and Mandarin, and condense it into 200 words... we saw an opportunity to show you two completely different approaches to the same ambiguous problem.

Mike (CTO) took the engineering route: Claude Code in terminal, planning phases, validation agents, citation checking, and systematic translation with dialect considerations.

Justin (CEO) went full marketing: scrollable website, Roaring Twenties aesthetic, personality woven throughout, and creative ways to stand out in a sea of AI generated submissions.

The truth? They're both testing the same thing. How do you break down an ambiguous task? How do you demonstrate your thought process? How do you use AI as a tool while showing your unique problem solving approach?

This isn't just about landing a government job. It's about the future of interviews in an AI world. Show your work. Demonstrate your thinking. Stand out with your approach, not just your output.

🔗 Original Job Post: https://x.com/SamCorcos/status/201229...
🔗 Job Listing: https://www.usajobs.gov/job/854817200
🔗 Justin's V0 Webpage: https://v0.app/chat/gatsby-treasury-e...

Chapters:

00:00 Intro: Applying for a $195K Government Job
02:30 Breaking Down the Supplemental Assignment
08:20 Mike's Technical Approach with Claude Code
21:30 Planning Mode and Context Management
32:00 Justin's Creative Marketing Approach
46:00 Translation Challenges: Spanish and Mandarin
54:00 Final Results: Engineering vs Marketing
01:02:00 Key Lessons: Process Over Output

Follow Sam Corcos: @samcorcos on X
Forward to Extraordinary.

Installing DaisyUI in Rails without Node.js

Mike Rispoli — Wed, 19 Nov 2025 21:36:13 +0000

I've been very intrigued by the no build frontend style of Rails 8+ and have begun a number of applications with a goal of sticking to this style. One area of difficulty though is that I love tailwind and namely DaisyUI.

The standard install in a node project requires npm and some build scripting but I wanted to add this to my rails application without needing to introduce Node.js. The following is how I did that.

I liked coupling this with the hotwire-spark gem to get hot reloading which gives the feeling of the hot reloading node frameworks I was used to but without the node for rails projects.

Prerequisites

Rails 8+ with tailwindcss-rails gem installed
Tailwind CSS v4 configured
Asset pipeline (Propshaft or Sprockets)

Installation Steps

1. Create Plugin Directory

mkdir -p app/assets/tailwind/plugins

2. Download DaisyUI Standalone Module

DaisyUI provides a standalone ESM module that can be used without npm:

curl -o app/assets/tailwind/plugins/daisyui.js https://cdn.jsdelivr.net/npm/daisyui@5/+esm

This downloads the complete DaisyUI library (~242KB) as a single JavaScript file.

Note: The file is bundled with your application - no external CDN calls at runtime.

3. Configure Tailwind to Use DaisyUI Plugin

Edit app/assets/tailwind/application.css:

@import "tailwindcss";
@plugin "./plugins/daisyui.js";

Important: The path is relative to the CSS file location.

4. Build Tailwind CSS

bin/rails tailwindcss:build

You should see output confirming DaisyUI loaded:

/*! 🌼 daisyUI 5.5.0 */
≈ tailwindcss v4.1.16
Done in 112ms

Note: You may see a warning about @property --radialprogress. This is harmless - it's a newer CSS feature that DaisyUI uses for circular progress components.

Using DaisyUI Components

Once installed, all DaisyUI component classes are available:

Example: Alert Component

<div class="alert alert-success">
  <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6 shrink-0 stroke-current" fill="none" viewBox="0 0 24 24">
    <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 12l2 2 4-4m6 2a9 9 0 11-18 0 9 9 0 0118 0z" />
  </svg>
  <span>Your purchase has been confirmed!</span>
</div>

Example: Card Component

<div class="card bg-base-100 shadow-xl">
  <div class="card-body">
    <h2 class="card-title">Card Title</h2>
    <p>Card content goes here</p>
    <div class="card-actions justify-end">
      <button class="btn btn-primary">Action</button>
    </div>
  </div>
</div>

Example: Form Components

<div class="form-control">
  <%= f.label :email, class: "label" %>
  <%= f.email_field :email, class: "input input-bordered w-full" %>
</div>

<button class="btn btn-primary">Submit</button>

Available DaisyUI Components

DaisyUI provides 50+ components:

Actions: Button, Dropdown, Modal, Swap
Data Display: Alert, Badge, Card, Table, Avatar
Data Input: Input, Textarea, Checkbox, Radio, Select, Toggle, Range
Layout: Divider, Drawer, Footer, Hero, Navbar
Navigation: Breadcrumbs, Menu, Pagination, Tabs
Feedback: Loading, Progress, Toast

Full list: https://daisyui.com/components/

Theming

DaisyUI includes multiple themes. Configure in app/assets/tailwind/application.css:

@import "tailwindcss";
@plugin "./plugins/daisyui.js";

/* Custom DaisyUI configuration */
@layer base {
  :root {
    --color-primary: oklch(45% .24 277.023); /* Custom purple */
  }
}

Or use built-in themes by adding to HTML:

<html data-theme="dark">
  <!-- Your app -->
</html>

Available themes: light, dark, cupcake, bumblebee, emerald, corporate, synthwave, retro, cyberpunk, valentine, halloween, garden, forest, aqua, lofi, pastel, fantasy, wireframe, black, luxury, dracula, cmyk, autumn, business, acid, lemonade, night, coffee, winter, dim, nord, sunset

Automatic Rebuilding in Development

The tailwindcss-rails gem automatically watches for changes in development.

Your Procfile.dev should include:

web: bin/rails server
css: bin/rails tailwindcss:watch

When running bin/dev, Tailwind automatically rebuilds when you:

Add new DaisyUI classes to views
Modify Tailwind configuration
Change CSS files

Production Deployment

Precompile Assets

RAILS_ENV=production bin/rails assets:precompile

This compiles Tailwind CSS with DaisyUI into app/assets/builds/tailwind.css.

Docker Deployment

Include the DaisyUI plugin file in your image:

# Dockerfile
COPY app/assets/tailwind ./app/assets/tailwind

# Precompile assets
RUN bin/rails tailwindcss:build

The compiled CSS is self-contained - no runtime dependencies on DaisyUI or Tailwind.

Upgrading DaisyUI

To upgrade to a newer version:

# Download latest version
curl -o app/assets/tailwind/plugins/daisyui.js https://cdn.jsdelivr.net/npm/daisyui@latest/+esm

# Rebuild
bin/rails tailwindcss:build

Or pin to a specific version:

curl -o app/assets/tailwind/plugins/daisyui.js https://cdn.jsdelivr.net/npm/daisyui@5.5.0/+esm

Troubleshooting

Issue: "Unknown at rule: @plugin"

Solution: Ensure you're using Tailwind CSS v4+. The @plugin directive is new in v4.

Issue: DaisyUI classes not working

Solutions:

Rebuild Tailwind: bin/rails tailwindcss:build
Check the plugin path is correct in application.css
Verify daisyui.js exists in app/assets/tailwind/plugins/

Issue: Styles not updating

Solution: Restart bin/dev to reload the Tailwind watcher.

Issue: Large file size

DaisyUI is ~242KB uncompressed. Tailwind CSS only includes classes you actually use in production, so the final CSS will be much smaller.

Comparison: NPM vs Standalone Method

Feature	NPM Method	Standalone Method
Node.js Required	✅ Yes	❌ No
npm/package.json	✅ Yes	❌ No
Build Process	Complex	Simple
Offline Deployment	Requires node_modules	✅ Fully self-contained
Update Process	`npm update`	`curl` new version
File Size	~242KB in node_modules	~242KB in assets
Production Output	Same	Same

Both methods produce identical CSS output. Choose standalone for simplicity and self-contained deployments.

Additional Resources

DaisyUI Documentation: https://daisyui.com/
Tailwind CSS v4: https://tailwindcss.com/
tailwindcss-rails gem: https://github.com/rails/tailwindcss-rails

Setting Up Solid Cache on Heroku with a Single Database

Mike Rispoli — Tue, 11 Nov 2025 15:08:49 +0000

I recently wanted to use Solid Cache for a new MVP I'm building out in Ruby on Rails. One thing I wanted was for this to all be deployed to a PaaS and in this case I was using Heroku. While I know Rails 8 pushes hard for Kamal and rolling your own deployment, for a lot of early projects it's nice to just have all the DevOps and CI/CD taken care of for you.

This creates a problem when it comes to Solid Cache. Rails recommends running these with SQLite and in fact I have a production application using SQLite for everything that works amazing. However, Heroku is an ephemeral application server and as such, wipes out your SQLite stores on every deployment.

Since this was an MVP I really just wanted to manage one database rather than introduce Redis or another instance of Postgres. After a lot of failed attempts and much googling, this was the solution I came up with.

The Problem

After deploying the Rails 8 application to Heroku, I encountered this error when trying to use rate limiting:

PG::UndefinedTable (ERROR: relation "solid_cache_entries" does not exist)

This occurred because Rails 8's rate limiting feature depends on Rails.cache, which in production is configured to use Solid Cache by default. However, the solid_cache_entries table didn't exist in our database.

This worked locally for me because in development Rails uses an in memory store so no database was required. It wasn't until deployment that I was able to see the error.

Understanding Solid Cache

Rails 8 introduces the "Solid" stack as default infrastructure:

Solid Cache - Database-backed cache store (replaces Redis/Memcached)
Solid Queue - Database-backed job queue (replaces Sidekiq/Resque)
Solid Cable - Database-backed Action Cable (replaces Redis for WebSockets)

By default, Rails 8 expects these to use separate databases. The solid_cache:install generator creates:

config/cache.yml - Cache configuration
db/cache_schema.rb - Schema file (NOT a migration)
Configuration pointing to a separate cache database

Why Use a Single Database on Heroku?

For our MVP, I chose to use a single PostgreSQL database for several reasons:

Cost and Simplicity

Heroku provides one DATABASE_URL - Additional databases cost extra
Simpler architecture - Fewer moving parts during initial development
Easier to manage - Single database connection, single backup strategy

Future Scalability Options

When you outgrow this setup, you have clear upgrade paths:

Redis - Better performance for high-traffic apps, separate caching layer
Separate PostgreSQL database - Isolate cache from primary data
Managed cache service - Heroku Redis, AWS ElastiCache, etc.

Why Not SQLite for Cache on Heroku?

While Solid Cache supports SQLite, Heroku's filesystem is ephemeral:

Files are wiped on dyno restart (at least once per 24 hours)
Deployments create new dynos with fresh filesystems
You'd lose all cached data frequently

SQLite-backed Solid Cache works great for:

Single-server VPS deployments (Kamal, Hetzner, DigitalOcean Droplets)
Containerized apps with persistent volumes
Development/staging environments

But for Heroku and similar PaaS platforms, use PostgreSQL or Redis for caching.

What I Tried (And What Didn't Work)

Attempt 1: Running the Generator

bin/rails solid_cache:install

Result: Created cache_schema.rb but no migration file. Changed cache.yml to point to a separate cache database that doesn't exist on Heroku.

Attempt 2: Official Multi-Database Setup

Following the official Rails guides, I configured database.yml with separate database entries:

production:
  primary:
    url: <%= ENV["DATABASE_URL"] %>
  cache:
    url: <%= ENV["DATABASE_URL"] %>  # Same database, different connection

And cache.yml:

production:
  database: cache

Result: The cache_schema.rb file wasn't loaded by db:migrate or db:prepare. Rails expected separate databases with separate schema files.

Attempt 3: Using db:prepare

Ran bin/rails db:prepare hoping it would load all schema files.

Result: Only loaded db/schema.rb (main migrations), ignored db/cache_schema.rb.

The Solution: Migration-Based Approach

After researching (including this Reddit thread), I found the working solution for single-database Heroku deployments.

Step 1: Configure cache.yml for Single Database

Remove the database: configuration from production in config/cache.yml:

# config/cache.yml
default: &default
  store_options:
    max_size: <%= 256.megabytes %>
    namespace: <%= Rails.env %>

development:
  <<: *default

test:
  <<: *default

production:
  <<: *default  # No database: specified - uses primary connection

Important: According to the Solid Cache README, when you omit database, databases, or connects_to settings, Solid Cache automatically uses the ActiveRecord::Base connection pool (your primary database).

Step 2: Create a Migration for the Cache Table

Generate a migration to create the solid_cache_entries table:

bin/rails generate migration CreateSolidCacheEntries --database=cache

The --database=cache flag keeps the migration organized (though it still runs against the primary database in our single-DB setup).

Step 3: Copy Table Definition from cache_schema.rb

Update the generated migration with the exact table structure from db/cache_schema.rb:

# db/migrate/YYYYMMDDHHMMSS_create_solid_cache_entries.rb
class CreateSolidCacheEntries < ActiveRecord::Migration[8.1]
  def change
    create_table :solid_cache_entries do |t|
      t.binary :key, limit: 1024, null: false
      t.binary :value, limit: 536870912, null: false
      t.datetime :created_at, null: false
      t.integer :key_hash, limit: 8, null: false
      t.integer :byte_size, limit: 4, null: false

      t.index :byte_size
      t.index [:key_hash, :byte_size]
      t.index :key_hash, unique: true
    end
  end
end

Step 4: Run Migration Locally

bin/rails db:migrate

Verify the table was created:

bin/rails runner "puts ActiveRecord::Base.connection.table_exists?('solid_cache_entries')"
# Should output: true

Step 5: Keep Development Simple

Leave development environment using :memory_store in config/environments/development.rb:

config.cache_store = :memory_store

This is the Rails convention and keeps development simple. Production uses Solid Cache, development uses in-memory caching.

Step 6: Deploy to Heroku

Your existing Procfile with the release phase will handle the migration:

release: bundle exec rails db:migrate
web: bundle exec puma -C config/puma.rb

Deploy and the migration runs automatically during the release phase.

Verification

After deployment, verify Solid Cache is working:

Check Heroku logs during release phase - should see migration run
Test rate limiting - Try to trigger rate limits on login endpoints
Check cache in Rails console:

   # On Heroku
   heroku run rails console

   # Test cache
   Rails.cache.write('test_key', 'test_value')
   Rails.cache.read('test_key')  # Should return 'test_value'

   # Check table
   SolidCache::Entry.count  # Should be > 0 if cache is working

Cache Expiration and Cleanup

Solid Cache includes automatic cleanup to prevent indefinite growth. Our configuration uses both size and age-based expiration:

# config/cache.yml
default: &default
  store_options:
    max_age: <%= 30.days.to_i %>     # Delete entries older than 30 days
    max_size: <%= 256.megabytes %>   # Delete oldest when exceeds 256MB
    namespace: <%= Rails.env %>

How Automatic Cleanup Works

Solid Cache uses a write-triggered background thread (not a separate job system):

Write tracking - Every cache write increments an internal counter
Automatic activation - After ~50 writes, cleanup runs on a background thread
Cleanup logic:
- If max_size exceeded → Delete oldest entries (LRU eviction)
- If max_age set and size OK → Delete entries older than max_age
- Deletes in batches of 100 entries (expiry_batch_size)
SQL-based deletion - Runs standard SQL DELETE queries:

   DELETE FROM solid_cache_entries
   WHERE created_at < NOW() - INTERVAL '30 days'
   LIMIT 100

Important Characteristics

✅ No Solid Queue required - Uses built-in Ruby threads, not Active Job
✅ No cron jobs needed - Self-managing and automatic
✅ Database-agnostic - Pure SQL, works with any ActiveRecord adapter
✅ Efficient - Background thread idles when cache isn't being written to
⚠️ Write-dependent - Cleanup only triggers when cache receives writes

For rate limiting (which writes on every login attempt), this mechanism works perfectly and requires no additional infrastructure.

Why 30 Days for Rate Limiting?

Rate limiting data is inherently short-lived:

Rate limit windows are 3 minutes
Session data expires in days, not months
Old cache entries from expired sessions serve no purpose

30 days is generous for this use case and prevents cache bloat while maintaining safety margins.

Key Takeaways

Rails 8's default Solid Stack assumes multi-database setup - This doesn't match Heroku's single DATABASE_URL model
Schema files aren't migrations - db/cache_schema.rb won't be loaded by db:migrate
Omitting database: in cache.yml uses the primary connection - This is the key for single-database setups
Create a regular migration - Convert the schema file to a migration for single-database deployments
SQLite doesn't work on ephemeral filesystems - Use PostgreSQL or Redis for caching on Heroku
Development can use :memory_store - No need to complicate local development
Automatic cleanup is built-in - Solid Cache handles expiration via background threads, no Solid Queue or cron jobs required

Future Migration Path

When your app scales and you need better cache performance:

Add Heroku Redis (~$15/month for hobby tier)
Update production.rb:

   config.cache_store = :redis_cache_store, { url: ENV['REDIS_URL'] }

Remove Solid Cache dependency if desired, or keep for other purposes

The migration is straightforward and won't require code changes beyond configuration.

Additional Resources

Setting up an encrypted secondary drive on Linux

Mike Rispoli — Mon, 10 Nov 2025 15:15:30 +0000

I recently received my brand new maxed out Framework Desktop and immediately installed Omarchy on it. However, I purchased a secondary drive and realized I had never actually had a second drive in my machine before. I went down the rabbit hole of setting this one up with full disk encryption and automatic mounting so you don't have to.

Spoiler alert, Claude code helped me with a lot of this, however I wanted to have a complete breakdown of everything we did so that I could a. reference it later and b. double check all of the things it was telling me to do so I didn't brick my machine. What follows is the exact setup I am using. My secondary drive is accessible from my home directory, is encrypted just like my main drive, mounts on startup, and doesn't require me to enter a password for this drive on every restart.

Introduction
What We're Doing
Prerequisites
Step-by-Step Guide
- Step 1: Partitioning the Drive
- Step 2: Setting Up LUKS Encryption
- Step 3: Creating a Key File for Auto-Unlock
- Step 4: Formatting with btrfs
- Step 5: Mounting and Setting Permissions
- Step 6: Configuring Auto-Mount at Boot
- Step 7: Testing the Configuration
Understanding the Final Setup
Troubleshooting
Useful Commands

Introduction

This guide walks you through setting up a secondary hard drive on Omarch Linux (an Arch-based distribution) running on a Framework Desktop. The setup includes:

Full disk encryption using LUKS (Linux Unified Key Setup)
btrfs filesystem (same as your main drive)
Automatic unlocking and mounting at boot
Proper permissions for your user account

Time required: ~15-20 minutes
Difficulty: Intermediate (but explained for beginners!)
Risk: Low (we're only working with the secondary drive, not your main system drive)

What We're Doing

Your Framework Desktop has two 2TB NVMe drives:

Primary drive (/dev/nvme0n1): Contains your operating system and home directory
Secondary drive (/dev/nvme1n1): Empty drive we'll set up for data storage

We'll set up the secondary drive to:

Be encrypted (like your main drive) for security
Automatically unlock when you boot (using a key file stored on your encrypted main drive)
Mount at /home/<your_username>/storage so you can easily access it
Use the btrfs filesystem for modern features like snapshots and compression

Why this approach?

Security: Your data is encrypted, so if someone physically removes the drive, they can't access it
Convenience: You only enter one password at boot (for your main drive), and the secondary drive unlocks automatically
Consistency: Using the same filesystem (btrfs) as your main drive keeps things familiar

Prerequisites

Before starting, ensure you have:

[x] Admin (sudo) access to your system
[x] Your user account password
[x] At least 10-15 minutes of uninterrupted time
[x] A backup of any data currently on the secondary drive (we'll erase everything!)

Check your sudo access:

sudo whoami

This should return root. If you get an error, you may need to fix your sudo configuration first.

In my case, with a fresh installation of Omarchy, I had to run omarchy-reset-sudo to fix it as per this issue.

Step-by-Step Guide

Step 1: Partitioning the Drive

What is partitioning?
Think of partitioning like dividing a physical hard drive into separate sections. Even though we have one physical drive, we can create multiple partitions that act like separate drives. For this setup, we'll create one large partition that uses the entire drive.

What is GPT?
GPT (GUID Partition Table) is the modern partitioning scheme that replaced the older MBR (Master Boot Record). It's required for drives larger than 2TB and works better with modern UEFI systems (which your Framework Desktop uses).

Command:

sudo parted /dev/nvme1n1 --script mklabel gpt mkpart primary 0% 100%

Breaking it down:

sudo: Run this command with administrator privileges
parted: The partitioning tool we're using
/dev/nvme1n1: The device name for your second NVMe drive
- /dev/ is where Linux stores device files
- nvme1n1 means NVMe drive #1 (counting from 0, so 0 is first, 1 is second)
--script: Run in non-interactive mode (don't ask for confirmation)
mklabel gpt: Create a new GPT partition table
mkpart primary 0% 100%: Create a primary partition using 0% to 100% of the drive (the whole thing)

Verify it worked:

lsblk /dev/nvme1n1

You should now see /dev/nvme1n1p1 (the "p1" means "partition 1").

Step 2: Setting Up LUKS Encryption

What is LUKS?
LUKS (Linux Unified Key Setup) is the standard encryption system for Linux. It encrypts your entire partition, making the data unreadable without the correct password (passphrase). Even if someone physically steals your drive, they can't access the data without your passphrase.

Command:

sudo cryptsetup luksFormat /dev/nvme1n1p1

Breaking it down:

cryptsetup: The tool for managing encrypted volumes
luksFormat: Initialize LUKS encryption on a partition
/dev/nvme1n1p1: The partition we just created

What happens when you run this:

You'll see a warning that this will erase all data (type YES in all caps to confirm)
You'll be asked to create a passphrase
You'll need to enter it twice to confirm

Important notes about the passphrase:

This is a backup unlock method - you won't need it for daily use (we'll set up automatic unlocking next)
Write it down and store it somewhere safe!
If you lose both this passphrase AND the key file we create later, your data is permanently lost
Make it strong but memorable (passphrase example: "correct horse battery staple")

Step 3: Creating a Key File for Auto-Unlock

What is a key file?
A key file is a file containing random data that acts like a password. Instead of typing a passphrase every time you boot, the system reads this file automatically. Since this file is stored on your encrypted main drive, it's protected by your main drive's encryption.

Think of it like this:

Your main drive is a locked safe (encrypted with your boot password)
Inside that safe, you store a key to another safe (the key file for your secondary drive)
When you unlock the first safe, you automatically have access to the key for the second safe

Commands:

Create a secure directory for key files:

sudo mkdir -p /root/keyfiles

mkdir: Make directory
-p: Create parent directories if needed
/root/keyfiles: Location in the root user's home directory (only accessible by root)

Generate a random key file:

sudo dd if=/dev/urandom of=/root/keyfiles/storage.key bs=1024 count=4

dd: "Data duplicator" - copies data from one place to another
if=/dev/urandom: Input file is /dev/urandom (a source of random data)
of=/root/keyfiles/storage.key: Output file (where to save the key)
bs=1024: Block size of 1024 bytes (1 kilobyte)
count=4: Create 4 blocks (total size: 4KB of random data)

Secure the key file permissions:

sudo chmod 600 /root/keyfiles/storage.key

chmod: Change file mode (permissions)
600: Only the owner (root) can read and write; no one else can access it
- First digit (6): Owner can read (4) + write (2) = 6
- Second digit (0): Group has no permissions
- Third digit (0): Others have no permissions

Add the key file to LUKS:

sudo cryptsetup luksAddKey /dev/nvme1n1p1 /root/keyfiles/storage.key

luksAddKey: Add a new way to unlock this encrypted partition
You'll be asked for the passphrase you created in Step 2 (to prove you're authorized to add a new key)
After this, the drive can be unlocked either with the passphrase OR the key file

Step 4: Formatting with btrfs

What is a filesystem?
A filesystem determines how data is organized and stored on a partition. Think of it like the filing system in a library - it defines how books (files) are organized, cataloged, and retrieved.

Why btrfs?
Btrfs (B-tree File System, pronounced "butter fs" or "better fs") is a modern filesystem with advanced features:

Snapshots: Take instant backups of your entire drive
Compression: Automatically compress files to save space
Data integrity: Checks for and repairs corruption
Subvolumes: Create separate "sub-filesystems" within one partition

Your main Omarch drive uses btrfs, so using it for your secondary drive keeps things consistent.

Commands:

Unlock (open) the encrypted partition:

sudo cryptsetup open /dev/nvme1n1p1 storage --key-file /root/keyfiles/storage.key

cryptsetup open: Unlock an encrypted partition
/dev/nvme1n1p1: The encrypted partition
storage: The name to give this unlocked device (it will appear as /dev/mapper/storage)
--key-file: Use the key file instead of prompting for a passphrase

Format with btrfs:

sudo mkfs.btrfs -L "Storage" /dev/mapper/storage

mkfs.btrfs: Make a btrfs filesystem
-L "Storage": Give it a label called "Storage" (appears in file managers)
/dev/mapper/storage: The unlocked encrypted partition

What you'll see:
The command outputs information about your new filesystem:

UUID: A unique identifier for this filesystem
Node size: How btrfs organizes metadata (16KB is standard)
Filesystem size: Total capacity (1.82TB)
SSD detected: Btrfs optimizes for SSD/NVMe drives automatically
Features: Modern btrfs features enabled

Step 5: Mounting and Setting Permissions

What is mounting?
Mounting is the process of making a filesystem accessible at a specific location in your directory tree. Think of it like assigning a drive letter in Windows (C:, D:, etc.), except in Linux you can mount drives anywhere in your folder structure.

Commands:

Create the mount point:

mkdir -p /home/<your_username>/storage

Creates a directory at /home/<your_username>/storage where we'll access the drive
This is just an empty folder right now

Mount the filesystem:

sudo mount /dev/mapper/storage /home/<your_username>/storage

mount: Make a filesystem accessible
/dev/mapper/storage: The unlocked encrypted drive
/home/<your_username>/storage: Where to mount it

Now when you access /home/<your_username>/storage, you're actually reading/writing to the encrypted drive!

Set ownership:

sudo chown <your_username>:<your_username> /home/<your_username>/storage

chown: Change ownership
<your_username>:<your_username>: User '' and group '' (your username)
Without this, only root could write to the drive

Step 6: Configuring Auto-Mount at Boot

The goal: Make the drive unlock and mount automatically when you boot your computer.

Two configuration files are involved:

/etc/crypttab (Crypto Tab)

This file tells the system which encrypted partitions to unlock at boot and how to unlock them.

/etc/fstab (File System Tab)

This file tells the system which filesystems to mount at boot and where to mount them.

Commands:

Get the UUID of the encrypted partition:

sudo blkid /dev/nvme1n1p1

blkid: Block device ID - shows information about partitions
You'll see output like: UUID="b57373d9-72d9-4ec7-9354-8f3cd61d3df4" TYPE="crypto_LUKS"
Copy the UUID (the long string of numbers and letters)

Add to /etc/crypttab:

echo "storage UUID=b57373d9-72d9-4ec7-9354-8f3cd61d3df4 /root/keyfiles/storage.key luks" | sudo tee -a /etc/crypttab

Breaking it down:

echo: Output text
The text is: storage UUID=YOUR-UUID /root/keyfiles/storage.key luks
- storage: Name for the unlocked device (will appear as /dev/mapper/storage)
- UUID=...: Identifies which encrypted partition to unlock
- /root/keyfiles/storage.key: Path to the key file to use for unlocking
- luks: This is a LUKS-encrypted partition
|: Pipe - send the output to the next command
sudo tee -a /etc/crypttab: Append to the /etc/crypttab file
- tee: Write to a file and also show output
- -a: Append (don't overwrite)

Add to /etc/fstab:

echo "/dev/mapper/storage /home/<your_username>/storage btrfs defaults 0 2" | sudo tee -a /etc/fstab

Breaking it down:
The text is: /dev/mapper/storage /home/<your_username>/storage btrfs defaults 0 2

/dev/mapper/storage: The device to mount (your unlocked encrypted drive)
/home/<your_username>/storage: Where to mount it
btrfs: The filesystem type
defaults: Use default mount options (read-write, auto-mount, etc.)
0: Don't dump (used by backup tools, 0 means skip)
2: Filesystem check order (0=don't check, 1=check first, 2=check after root)

What happens at boot now:

System reads /etc/crypttab
Unlocks /dev/nvme1n1p1 using the key file, creating /dev/mapper/storage
System reads /etc/fstab
Mounts /dev/mapper/storage at /home/<your_username>/storage
Your drive is ready to use!

Step 7: Testing the Configuration

Before rebooting, let's test that everything works correctly.

Commands:

Unmount and close the drive:

sudo umount /home/<your_username>/storage
sudo cryptsetup close storage

This simulates the state before boot (drive locked and unmounted)

Reload systemd and test auto-mount:

sudo systemctl daemon-reload
sudo systemctl restart cryptsetup.target
sudo mount -a

systemctl daemon-reload: Reload systemd configuration files
systemctl restart cryptsetup.target: Trigger encryption unlock (reads /etc/crypttab)
mount -a: Mount all filesystems in /etc/fstab that aren't already mounted

Verify it's mounted:

df -h | grep storage

df -h: Show disk free space in human-readable format
| grep storage: Filter to only show lines containing "storage"
You should see /dev/mapper/storage mounted at /home/<your_username>/storage

Test that you can write to it:

echo "Test file - LLMs will go here!" > /home/<your_username>/storage/test.txt
cat /home/<your_username>/storage/test.txt

Creates a test file and reads it back
If this works, your permissions are correct!

Understanding the Final Setup

What You Have Now

Physical layout:

/dev/nvme1n1 (2TB NVMe drive)
└── /dev/nvme1n1p1 (2TB partition, LUKS encrypted)
    └── /dev/mapper/storage (unlocked encrypted partition, btrfs filesystem)
        └── /home/<your_username>/storage (mounted and accessible)

At boot:

You enter your main drive password
System unlocks your main drive (containing your OS and the key file)
System reads /root/keyfiles/storage.key from your main drive
System automatically unlocks /dev/nvme1n1p1 using the key file
System mounts it at /home/<your_username>/storage
Ready to use!

Security model:

Both drives are encrypted
Only one password needed at boot
Key file is protected by your main drive's encryption
If someone steals just the secondary drive, they can't access it (no key file)
If someone steals both drives but doesn't have your password, neither drive can be accessed

Troubleshooting

Drive not mounting at boot

Check if it's unlocked:

ls /dev/mapper/

You should see storage in the list.

If not, check /etc/crypttab syntax:

cat /etc/crypttab | grep storage

Permission denied when writing to drive

Fix ownership:

sudo chown -R <your_username>:<your_username> /home/<your_username>/storage

Want to manually unlock/mount

Unlock:

sudo cryptsetup open /dev/nvme1n1p1 storage --key-file /root/keyfiles/storage.key

Mount:

sudo mount /dev/mapper/storage /home/<your_username>/storage

Want to manually unmount/lock

Unmount:

sudo umount /home/<your_username>/storage

Lock:

sudo cryptsetup close storage

Forgot your LUKS passphrase

If you still have access to the key file, you can:

Unlock with the key file: sudo cryptsetup open /dev/nvme1n1p1 storage --key-file /root/keyfiles/storage.key
Change the passphrase: sudo cryptsetup luksChangeKey /dev/nvme1n1p1

Need to add another way to unlock (second key file or passphrase)

sudo cryptsetup luksAddKey /dev/nvme1n1p1 /path/to/new/keyfile

Or to add a new passphrase:

sudo cryptsetup luksAddKey /dev/nvme1n1p1

Useful Commands

Check drive usage

df -h /home/<your_username>/storage

Check encryption status

sudo cryptsetup status storage

View LUKS header information

sudo cryptsetup luksDump /dev/nvme1n1p1

See all block devices

lsblk -f

Check btrfs filesystem info

sudo btrfs filesystem show /home/<your_username>/storage

Create a btrfs snapshot (instant backup)

sudo btrfs subvolume snapshot /home/<your_username>/storage /home/<your_username>/storage/.snapshots/snapshot-$(date +%Y%m%d)

Use Cases

Now that your drive is set up, here are some great uses:

Storing Local LLMs

Large language models can be 4GB to 70GB+ each:

mkdir -p /home/<your_username>/storage/llms
cd /home/<your_username>/storage/llms
# Download your models here

Media Storage

mkdir -p /home/<your_username>/storage/{movies,music,photos}

Development Projects

mkdir -p /home/<your_username>/storage/projects
cd /home/<your_username>/storage/projects
git clone https://github.com/yourproject

Backups

mkdir -p /home/<your_username>/storage/backups
rsync -av /home/<your_username>/important-data /home/<your_username>/storage/backups/

Conclusion

Congratulations! You've successfully set up an encrypted secondary drive with automatic unlocking and mounting. Your Framework Desktop now has:

🔒 Security: Full disk encryption on both drives
⚡ Convenience: One password unlocks everything
💾 Capacity: 1.8TB of additional storage
🎯 Modern: Using btrfs with snapshots, compression, and integrity checking

Store your LUKS passphrase safely, and enjoy your expanded storage!

Document Information

Created: 2025-11-09
System: Omarch Linux (Arch-based)
Hardware: Framework Desktop
Drive: 2TB NVMe (/dev/nvme1n1)
Mount Point: /home//storage
Filesystem: btrfs
Encryption: LUKS with key file auto-unlock

Questions or Issues?
Refer to the Arch Wiki for detailed documentation:

Calculating Quarterly Taxes as a Freelancer

Mike Rispoli — Thu, 09 Jan 2025 18:01:10 +0000

Calculating your taxes as a freelancer can be a daunting task. Often times we don't know exactly how much we will make come year end. If you overpay early in the year, it can leave you short on cash at the end, with no refund until the following year. What's a freelancer to do?

This was one of the major reasons I built fin. It helps you forecast your contracts against your expenses to see the reality of where you will end up.

Important note, this is does not constitute financial advice. The exact amount you will owe for taxation is based on many factors so ultimately you should review this with your accountant.

For those that don't want to read on, I made a video showcasing this below:

Let's say that I sign a 6 month contract here in January for $12,000.00 per month. When it comes time to compute my taxes for quarter one in April, my accountant typically assumes this to be a steady trend throughout the year. Therefore, I would compute my quarterly tax burden based on the net income of $36,000.00.

I'll add this income to Fin and take a look at the cumulative vs. month over month recurring revenue.

The obvious first problem here is that I'm not taking into account any expenses, which is easy enough to remedy by tracking and deducting those from my total income.

I'll add some expenses to my freelance practice and we can now see how this lays out for quarter one.

With our expenses added we can say that we should plan to pay quarterly taxes on an income of $30,276.60. But what if we fail to secure another contract in July?

Therin lies the problem with calculating our taxes this way. Using fin we can see how the next 12 months of our future looks if we fail to sign any new customers.

We end the year with a profit of $49,106.40 far below our expectations when we cut a check for quarter one. This is the fear of every freelancer, we don't want to overpay our quarterly taxes and end up short on cash at the end of the year if we fail to secure another contract.

In 2024 this was a reality for many as tech contracts dried up and work became harder to secure. With Fin, we can see further into the future and assess our risks accordingly.

Now let's say we secure a contract for July through September but at a lower monthly rate of $8,000.00 per month. This changes our month over month projection to look more like this:

We can see a bit further into the future now but there's still a real risk we sign no contracts at the end of the year. Now we can see this and take a look at what our 12 month is instead of what it looks like at that point in time.

You can also see that come October we're going to need to begin dipping into our harvested profits to cover our ongoing expenses.

Ultimately, if we hold some cash back and use our 12-month net profit projection come June, we can cover the downside nicely should we hit a dry spell in terms of work. Otherwise we'd be forced to leverage credit cards and rely on a tax refund the following year to make up for the cash shortage.

Kamal 2 Quick Start - the missing tutorial

Mike Rispoli — Wed, 08 Jan 2025 16:13:48 +0000

Kamal is the new out of the box deployment tool that comes with Ruby on Rails. I'm assuming you already know this and are trying to get up and running quickly so let's skip the formality and get right into it.

Step 1: Get Docker

Yes, you do need to sign up for a Docker account first. Go to https://www.docker.com and sign up for an account. This will take you to your Docker Hub.

From there you will want to select a private repository for your project unless you want your build artifacts made public.

Step 2: Download Docker Desktop

Now you should download docker desktop and install. You should then be able to run docker login in your terminal and log in with your credentials. However, you don't want to necessarily log in with your password for you deploys. You'll want to use an access token instead...

Step 3: Create an Access Token

Go to settings -> personal access tokens in Docker Hub and you can create a token there. Here's the link if you are already logged in: https://app.docker.com/settings/personal-access-tokens.

Now try to run docker login and enter the access token you just generated as a password. It should succeed.

Step 4: Save to .env File

Now what you are going to want to do is create a .env file at the root of your Rails app. This is the part where AI will fail you and the existing documentation is sparse. Do not store this in your encrypted credentials like your other secrets. Kamal specifically looks for this in a .env file.

You should also not commit this to source, Rails by default will have this in the .gitignore file so you should be able to see it's not getting committed after creation.

Step 5: Update Your deploy.yml

Open the config/deploy.yml file. Here we can make some updates.

Update the service value with the name of your app.
Update the image value with your username slash the name of your app: <your_docker_username>/<name_of_app>
Under servers -> web add the IP Address of your deploy target. If this is Digital Ocean like I used, this is the public IP of the server found in the admin panel.
Under proxy you will want the ssl value to stay true if you want an ssl to be generated and the host will be the URL of your app including subdomain if you are deploying to a subdomain.
Under registry -> username put your Docker username. Leave the password value as is - KAMAL_REGISTRY_PASSWORD.

Note: If you are just testing this and want to have it so you can hit the public IP address of your server in your browser without a domain name, first set the ssl value to false and set the host to the public IP address of the server for testing under servers.

Everything else can remain as is. Here's what it should look like:

# Name of your application. Used to uniquely configure containers.
service: <YOUR_APPLICATION_NAME>

# Name of the container image.
image: <YOUR_DOCKER_USERNAME>/<YOUR_APPLICATION_NAME>

# Deploy to these servers.
servers:
  web:
    - <YOUR_SERVER_IP_ADDRESS>
  # job:
  #   hosts:
  #     - 192.168.0.1
  #   cmd: bin/jobs

# Enable SSL auto certification via Let's Encrypt (and allow for multiple apps on one server).
# Set ssl: false if using something like Cloudflare to terminate SSL (but keep host!).
proxy:
  ssl: true
  host: <YOUR_DOMAIN_NAME_INCLUDING_SUBDOMAIN_IF_APPLICABLE>

# Credentials for your image host.
registry:
  # Specify the registry server, if you're not using Docker Hub
  # server: registry.digitalocean.com / ghcr.io / ...
  username: <YOUR_DOCKER_USERNAME>

  # Always use an access token rather than real password when possible.
  password:
    - KAMAL_REGISTRY_PASSWORD

Step 6: Deploy Time!

Ok, now this last part is very important, it's time to deploy your app. First, make sure that you can ssh into the deploy target from your machine. I like to setup a firewall that only allows my IP Address to SSH into the machine so before you deploy make sure you can ssh root@<YOUR_SERVER_IP_ADDRESS> before running deploy.

If you have just set this server up you'll want to run dotenv kamal setup first so that it installs docker and all dependencies on the remote server.

Now you can run dotenv kamal deploy and everything should run in your terminal and complete.

That dotenv piece deals with the fact that for some reason Kamal 2 cannot find the .env file by default. After much skimming of git issues and yelling at LLM's I arrived at that single glorious comment. Simply use dotenv kamal deploy and all should work as expected.

I hope this helps with your first Kamal 2 deploy.

Format on save for ERB and Ruby files in Zed IDE

Mike Rispoli — Tue, 15 Oct 2024 16:50:58 +0000

Something that I really wanted when working with (Zed)[https://zed.dev] and Ruby on Rails was format on save ability for my .rb and .erb files. The setup is simple so I thought I'd give it a share:

First open your settings.json file with cmnd + , or going to Zed -> Settings -> Open Settings.

Then add a key for languages with the following:

{
  ...other_settings_here,
  "languages": {
    "Ruby": {
      "format_on_save": "on",
      "formatter": {
        "external": {
          "command": "./bin/bundle",
          "arguments": [
            "exec",
            "rubocop",
            "--auto-correct",
            "--stdin",
            "corrected.rb",
            "--stderr"
          ]
        }
      }
    },
    "ERB": {
      "formatter": [
        {
          "external": {
            "command": "sh",
            "arguments": [
              "-c",
              "f=erblinttemp_$RANDOM$RANDOM.html.erb; cat > $f; erblint -a $f &>/dev/null; cat $f; rm $f;"
            ]
          }
        },
        {
          "external": {
            "command": "htmlbeautifier",
            "arguments": []
          }
        }
      ],
      "format_on_save": "on"
    }
  }
}

There you have it format on save for your template files and ruby files ready to go.

Kicking the tires with NestJS and Hotwire: Part II

Mike Rispoli — Wed, 15 Nov 2023 13:03:41 +0000

I recently experimented with using Hotwire, the HTML-over-the-wire approach that comes default with the Ruby on Rails framework but with a node.js based backend. My goal was to try the paradigm out using a language I am familiar with, Typescript, to determine if this is a better developer experience and paradigm in general to build web applications with.

If you haven't seen part one for the initial setup and tour, check it out here: Part I: How to Build an App with Nestjs and Hotwire

Implementing Hotwire with NestJS

If you want more details on the initial setup I encourage you to take a look at the Part I that covers more of the initial implementation. For this portion, I added Prisma as an ORM, a frontend style library called Tachyons, and AlpineJS to handle any client-side interactions. I did this to avoid needing to add a client-side bundler to the build and instead just rely on plain old module imports to compose the frontend. This is now the default for Rails and it is quite nice to not need any additional build tools for the client.

I chose Tachyons over Tailwind because Tachyons is an atomic CSS framework, similar to Tailwind, however it's much lighter weight. Tailwind tends to be a bit heavier without using post CSS processing so I wanted to stick with something smaller.

I chose AlpineJS over the Hotwire default of Stimulus because Alpine does provide a lot of nice modules and features like modals and focus lock for accessibility that can be a pain to implement on your own. I think Alpine really has some great features that you will appreciate if you were going to build something more robust with this.

Broadcasting Updates and Security Concerns

A key benefit of Hotwire is streaming updates to multiple connected clients. However, this can also be a security risk. The vast majority of apps I've worked on do not require this type of functionality so broadcasting every user's updates to every connected client is a security risk in most cases.

You could potentially avoid using turbo streams and just return the right HTML in the standard response of your API calls via turbo frames. The problem here is if an update requires you to update multiple components or frames on the page you would either need to specify the target=_top property and refresh all the frames. However, this method could become heavy. Turbo streams allow us to target specific elements and update them by DOM selector.

For example here we update the messages list as well as the messages count at the top of the page in a single turbo stream event:

<turbo-stream action="append" targets="#messages ul">
  <template>
    <li id="message_{{message.id}}_list_item" class="bb pv3">
      <turbo-frame id="message_{{message.id}}">
        {{> message message=message}}
      </turbo-frame>
    </li>
  </template>
</turbo-stream>
<turbo-stream action="update" target="messages-count">
  <template>
    <turbo-frame id="messages-count">
      <strong class="db mv3">Messages Count:
        {{messagesCount}}</strong>
    </turbo-frame>
  </template>

There are really three core scenarios we need to cover:

Updating only the user's client
Updating everyone's client
Updating only select authorized clients

I came decided to implement a broadcastTo flag that allowed for broadcasting updates to self, all, or with-permissions. The last type would allow you to pass a predicate function to the controller where you could execute your authorization logic. As this is just a simple demo I left the with-permissions and predicate function for a later day.

return fromEvent(this.eventEmitter, 'turbo-stream.event').pipe(
      map(
        (payload: {
          template: string;
          requestStreamId: string;
          broadcastTo: 'self' | 'all' | 'with-permissions';
          predicate?: (req: Request) => Promise<boolean>;
        }) => {
          switch (payload.broadcastTo) {
            case 'all':
              return {
                data: payload.template,
              } as MessageEvent;
            case 'self':
              if (
                !!payload.requestStreamId &&
                !!req.cookies['x-turbo-stream-id'] &&
                payload.requestStreamId === req.cookies['x-turbo-stream-id']
              ) {
                return {
                  data: payload.template,
                } as MessageEvent;
              }

              return;
            case 'with-permissions':
              // TODO: Implement permissions predicate
              return {
                data: payload.template,
              } as MessageEvent;
            default:
              // This should never happen
              return {} as never;
          }
        },
      ),
    );

I implemented a cookie-based solution to only broadcast updates to the appropriate clients. This means that any client that connects the turbo stream endpoint gets assigned a unique identifier. We need this even in applications without log in so we can still send streams to the client that made the request of our other controllers. For example an ecommerce application would have guest users that add items to cart and we would want to update their cart at the top of the page.

Here's some examples of calling the send event from a NestJS controller where we broadcast to all clients and just the requesting client or "self" respectively:

this.appService.sendTurboStreamEvent(req, {
      eventName: 'turbo-stream.event',
      template: 'turbo-streams/update-message',
      broadcastTo: 'all',
      data: { message: newMessage },
    });

this.appService.sendTurboStreamEvent(req, {
      eventName: 'turbo-stream.event',
      template: 'turbo-streams/create-message',
      broadcastTo: 'self',
      data: {
        message: newMessage,
        messagesCount,
      },
    });

That being said, I would be cautious using this method on anything production worthy. I put this together rather quickly and frameworks like Ruby on Rails, Laravel and Phoenix have been battle tested with this paradigm.

So while possible with NestJS, you'd likely need to implement additional security yourself before using Hotwire streams in a real app. While the Turbo docs cover the client side setup, you are left to dig into the Ruby on Rails setup if you want to uncover how this is implemented in the server.

Paradigm Shift from Declarative Frameworks

Coming from React, I noticed Hotwire requires more imperative DOM updates. Instead of just mutating state and letting the UI update, you explicitly target DOM elements to update.

This took some mental adjustment coming from React, however I can see the appeal as your updates are clean and straightforward to see based on action and targets set on the streams.

<turbo-stream action="append" targets="#messages ul">
  <template>
    ...
  </template>
</turbo-stream>
<turbo-stream action="update" target="messages-count">
  <template>
    ...
  </template>
</turbo-stream>

I also found going back to handlebars as a template language to be a bit lackluster. I do prefer JSX / TSX as a template language and feel if I were to take this further I would want to have a TSX to HTML implementation instead.

Performance and Scalability Unknowns

I'm curious how the server sent events would perform at scale compared to modern SPAs. While server sent events are more efficient than WebSockets, it's hard to know how well this would handle hundreds or thousands of connections.

I tend to not worry too much about scaling prematurely, however, you do want to have some idea of what scale could look like in terms of memory use and cost over time. In this case I'm not doing any benchmarking, but it would be something I would want to test before rolling out in production.

My gut feeling is that if you really love this paradigm there is one language and framework that stands out as designed precisely for this type of use case. Phoenix LiveView leveraging Elixir and running on top of BEAM, the ER Lang virtual machine, is the perfect tool for this job. I could also see GoLang being a nice contender for handling all of the connections, but of course you would have to build up that implementation yourself first.

Better Options for Production Apps

For me, NestJS with Hotwire seems like a fun experiment but not ideal for serious production apps yet. Modern meta-frameworks like NextJS, Nuxt, SvelteKit and others offer a better developer experience and confidence in scalability for the JavaScript ecosystem.

However, for developers using other languages, Hotwire is an incredible way to write more code in your favorite language and avoid the cognitive overhead of toggling between the frontend and backend in two different languages. If your language of choice doesn't have it's own HTML-over-the-wire style framework like Elixir, Ruby, and PHP--you should give Turbo a look for implementing this paradigm.

That being said, if you love this paradigm and have to learn a new language anyway to take advantage of this I feel Phoenix LiveView is probably the best place to put your efforts. It handles streaming and security out of the box and leverages Elixir/Erlang and the BEAM virtual machine for rock-solid scalability.

Final Takeaways

Hotwire with NestJS works well but the developer experience is likely not going to push you away from the popular meta frameworks like NextJS, Nuxt, or SvelteKit.
The paradigm shift from declarative frameworks like React takes some adjustment.
For production use, I definitely recommend using it with Ruby on Rails since the community has already handled most of the backend concerns.
You definitely don't need to implement a client side bundler if you don't want to anymore.
Phoenix LiveView feels like the right tool for this job if you had to learn something new.

Let me know if you have any other questions! I'm happy to discuss more.

How to build an app with nestjs and hotwire!

Mike Rispoli — Thu, 02 Nov 2023 18:38:47 +0000

TLDR; If you just want to fire up the code and try it out, here's the git repository: https://github.com/Cause-of-a-Kind/nest-hotwire-boilerplate

A few years ago, 37 Signals announced Hotwire, a new approach to building web applications without writing front-end JavaScript. Hotwire was developed by the team at 37 Signals while building Hey.com and allows you to have the responsiveness of a single-page app using only back-end code.

I've been intrigued by similar frameworks like Phoenix LiveView and Laravel Livewire, but as a JavaScript developer, I didn't want to have to learn a whole new backend language to try them out. While I had a bunch of Ruby on Rails experience a number of years ago, my knowledge of the framework has grown rusty.

Hotwire is backend agnostic, so I decided to test it out using NestJS, a Node.js framework that has an MVC structure similar to Rails. The idea is I could kick the tires on this new paradigm without my opinion being clouded by my unfamiliarity with a different backend language.

Hotwire is composed of three main libraries:

Turbo
Stimulus
Strada

What I focused on is Turbo for this demo. This is the library that powers the HTML over the wire (H-OT-WIRE) approach to building your application. Stimulus is specifically for manage your client side javascript, and isn't a required part of this. You can use plain Vanilla JS or you can use a different client-side library like Alpine JS as an alternative.

In the demo I go over the three main components of Turbo for web apps:

Turbo Drive
Turbo Frames
Turbo Streams

Let's dive in.

Turbo Drive

The first part of Hotwire I tried was Turbo Drive. This eliminates full page reloads when navigating between pages. To enable it, I simply added the Hotwire package script from Skypack to the document <head> and voila.

<head>
...
    <script type="module">
        import hotwiredTurbo from 'https://cdn.skypack.dev/@hotwired/turbo';
    </script>
...
</head>

With Turbo Drive, clicking between pages fetched the new page in the background and replaced the <body> contents instead of fully reloading.

Turbo Frames

Next, I added Turbo Frames, which are effectively the components of your application that can update independently of each other.

For example, I added a <turbo-frame> that loads a list of messages from the path in its src attribute. The contents of this initial frame serve as the loading state before that html is replaced by the server response from /messages.

<turbo-frame id="messages" src="/messages">
    <p>Loading...</p>
</turbo-frame>

I then created an endpoint that returns those messages as a fragment of HTML. You can serve this as a complete HTML document or just a piece of HTML like I have and Turbo will pluck that fragment from the response and swap it with the existing HTML.

  @Get('/messages')
  @Render('turbo-frames/messages')
  getMessages() {
    return {
      messages: this.appService.getMessages(),
    };
  }

Here's the turbo-frames/messages fragment:

<turbo-frame id="messages">
  <h1>Messages</h1>
  <ul>
    {{#each messages}}
      <turbo-frame id="message_{{this.id}}">
        <li>{{message.text}}</li>
        <a href="/messages/{{message.id}}/edit">Edit</a>
      </turbo-frame>
    {{/each}}
  </ul>
</turbo-frame>

And here's the result:

When clicking edit on a message, it loads the edit form into the frame without reloading the whole page. And this is really the paradigm shift you have to wrap your mind around if you're coming from another framework like React. Instead of managing the state of the UI on the client, we simply use standard link tags and Turbo loads the returned frame in place of what's there.

If you take a look at the code above again, we have another turbo-frame element inside of our messages frame that holds each message.

{{#each messages}}
  <turbo-frame id="message_{{this.id}}">
    <li>{{message.text}}</li>
    <a href="/messages/{{message.id}}/edit">Edit</a>
  </turbo-frame>
{{/each}}

When we click on the link, we create another endpoint that returns the new piece of UI we want to load in place of what is within that frame.

Here is our controller:

@Get('/messages/:id/edit')
  @Render('turbo-frames/edit-message')
  editMessage(@Param('id') id: string) {
    return {
      message: this.appService.findMessage(+id),
    };
  }

And this is the turbo-frames/edit-message template:

<turbo-frame id="message_{{message.id}}">
   <form action="/messages/{{message.id}}/edit" method="POST">
       <label>
           Message:
           <input type="text" name="text" value="{{message.text}}" />
       </label>
       <button type="submit">Update Message</button>
   </form>
</turbo-frame>

Which renders like this when we click edit:

We can submit the form just like a normal form without any client side js on our part. Our /messages/:id/edit endpoint can return the HTML fragment it should replace the form with. In this world the server just returns the new state of the world for our frames and Turbo will replace what's there with the response.

  @Post('/messages/:id/edit')
  @Render('turbo-frames/view-message')
  updateMessage(
    @Param('id') id: string,
    @Body('text') text: string,
  ) {
    const newMessage = this.appService.editMessage(+id, text);

    return {
      message: newMessage,
    };
  }

In this case, after submitting the form successfully, it switches back to our standard message view. Turbo Frames allow you to break the page into components that update independently.

Turbo Streams

The most exciting part was getting real-time updates working with Turbo Streams. This uses Server-Sent Events to push data updates from the server to the client.

I connected a stream source in my layout and set up an event emitter in NestJS. Now when a message is edited, it automatically streams the update to all connected clients.

So returning to our script in the <head> of our document we can add our connection.

<script type="module">
    import hotwiredTurbo, { connectStreamSource } from 'https://cdn.skypack.dev/@hotwired/turbo';

    const es = new EventSource("/turbo-streams");

    connectStreamSource(es);
</script>

Next we have to enable the /turbo-streams endpoint to allow for our client to connect to the server and receive events.

@Sse('/turbo-streams')
  async sse(): Promise<Observable<MessageEvent>> {
    return fromEvent(this.eventEmitter, 'turbo-stream.event').pipe(
      map((payload: { template: string }) => {
        return {
          data: payload.template,
        } as MessageEvent;
      }),
    );
  }

In this case, we're going to use and event emitter so that our backend can emit an event called turbo-stream.event and deliver the template as a payload to the client.

So now we can modify our edit messages controller to emit an event that will tell anyone else connected to the app to update their UI in real time.

This enables real-time features like chat without any of our own front-end code!

  @Post('/messages/:id/edit')
  @Render('turbo-frames/view-message')
  updateMessage(
    @Param('id') id: string,
    @Body('text') text: string,
    @Req() req: Request,
  ) {
    const newMessage = this.appService.editMessage(+id, text);

    this.appService.sendTurboStreamEvent(req, {
      template: 'turbo-streams/update-message',
      data: { message: newMessage },
    });

    return {
      message: newMessage,
    };
  }

I created a small helper in our app service to handle rendering the template string and emitting the event when complete.

sendTurboStreamEvent(
    req: Request,
    {
      template,
      data,
    }: {
      template: string;
      data: object;
    },
  ) {
    req.app.render(template, data, (_err, html) => {
      this.eventEmitter.emit('turbo-stream.event', {
        template: html,
      });
    });
  }

Now when if we load our application side by side with another instance you can see them both update automatically! This reminded me a lot of the magic that was baked into the Meteor framework, but with a lot less code.

Final Thoughts

I was impressed by how much I could build with Hotwire and NestJS. It seems promising for rapid prototyping and MVPs. I'm interested to try migrating an existing app that is using React to compare the difference. But now I can get a more accurate comparison being in the comfort of my daily programming language.

I've published the demo app code to GitHub if you want to try playing with Hotwire yourself. Let me know if you build something cool with it!

https://github.com/Cause-of-a-Kind/nest-hotwire-boilerplate

Is there a basic explanation of Web3 somewhere for my mom?

Mike Rispoli — Tue, 30 Aug 2022 14:49:59 +0000

There isn't, but there should be! 💡

Blockchain is a tool for building Web3, which to me simply means the internet of value (owning digital things). But that also means blockchain need not be a part of that equation at all.

To take advantage of it, your Mom shouldn't need to understand the inner mechanics. I have a refrigerator, what does it do? It keeps food cold. You needn't know the inner workings to take advantage of it's awesome power.

We all pay for goods with money, yet only a select few understand the economics behind fiat. Web3 needs to bridge that gap.

This might rub some purists the wrong way though. It means the average person cares very little about decentralization. What they will care about is being able to log in to applications without having to remember a password or transfer money from place to place without waiting for a clearing house or being charged a transaction fee.

God forbid we allow financial transactions to take place instantly, without paying a middleman... 🤯

I find Web3 seems to conflate the technology behind it with what makes it valuable to a consumer.

But would people be skeptical of HOW it allowed them to log in without a password like they are used to?

Does anyone know if those GDPR cookie popups actually work on every website? Do they ask how our passwords are stored?

I've met developers with years of experience that have no idea how traditional password-based authentication works. I'd imagine most people know even less than that with the tech we have right now.

Someone once told me the little red emergency brakes 🚨 on the train are actually connected to nothing. They're just there to make you feel good. I think of this metaphor a lot when browsing the web. So many popups, certifications, and legalese. Yet there are so many data leaks, breaches, and vulnerabilities on trusted platforms.

What I think is cool about Web3 is the idea that it will enable great security. How it achieves that will grow less and less important to consumers as it becomes mainstream.

The Secret UX of the Headless CMS

Mike Rispoli — Tue, 30 Aug 2022 13:48:41 +0000

With headless content management systems, designers and developers are given incredible power and flexibility. Power we never had with the monolithic solutions of the past like Wordpress, Drupal, Shopify, or Magento. The problem is that with great power and flexibility, comes great complexity. We spend a lot of time and energy on the design of our interfaces for customers. Yet, we think very little about the user experience of the back end systems that go into this.

The prevailing belief is that employees and administrators can suffer the pain as long as the user experience for customers is great. When it comes to the classical content management systems, many of us have been institutionalized. We're years away from the pain of learning our way around Wordpress or Drupal or BigCommerce. When we build for headless, a CMS like Contentful or Contentstack can be a dream. However, because the configuration is largely dependent on the developer setting it up, the user experience for your internal teams can manifest as a nightmare.

This is the side of headless that the industry itself still has not come around to. There is an entire user experience that now must be crafted behind the CMS itself. In fact, headless content management systems can be used to house far more than just content. At Cause of a Kind, we're using headless systems to build entire command and control centers for applications. They come complete with the ability to modify the content and imagery, craft event triggers with web hooks, and even modify the UI of the CMS itself. They give us everything we need not just to control our web interfaces, but also a way to tie together disparate internal systems. They help us wrangle a tangled ball of third-party systems into a neat pipeline of data. We can then safely give control of these systems to non-technical stakeholders.

This frees development teams from one line text changes and running simple scripts to migrate data from one system to another. We've used headless content management systems to build everything from complex brochure and e-commerce websites, to feature flag systems for continuous integration, all the way to medical software that aggregates data from remote devices. This type of power gives us the ability to deliver value faster to customers and more power to internal stakeholders. That being said, leaving this kind of UX design to a team of engineers is often the place where things go south.

Headless content management systems have created their own uncanny valley. The closer the system gets to a great user experience, the more intolerable things can become for users. For example, let's take an old school CMS like Joomla. When modified it becomes quite odd to use. It is riddled with terms like articles, modules, and components that end up representing different entities than we would expect. However, it is understood by the users that there will be a learning curve. They will have to memorize where these things go and what they will effect. The expectation is that this system WILL NOT be intuitive, and this is understood as soon as the user logs in.

With legacy content management systems, you didn't have to consider the user experience. The user experience was dictated for you. You suffered repurposing entities like posts, blocks, components, and articles for new use cases. Administrators decorated their monitors with post-it notes full of little tips for how to use the CMS. Internal stakeholders understood the tradeoff of using what's available to avoiding building something from scratch. These oddities became acceptable abstraction leaks and a challenging user experience was the expectation.

Contrast this with a headless content management system. Here, the workflows can be carefully crafted, entity terminology can matched to the industry, and custom plugins can make the editing experience more intuitive. The problem is, when users expect something intuitive and simple to use, yet it is not, that friction if felt ten fold! It's even worse when you get almost everything right.

So how do we get this right? You need to talk to the users! It's important during the process of configuring the CMS, that you, the engineer, sit down and talk with some users. Show them how you're thinking of configuring things. Ask them about their workflows and pain points. At Cause of a Kind the user flows in the back of the house make it to the story map and design documents.

We may not need UX designers to create mockups like we do for the customer facing application, but we certainly need to prototype. Before you hook up the CMS, create some models and fill in some data. Share it with the people that manage the system and ask for their feedback. You won't get things perfect, but you'll be able to cross that uncanny valley between expected discomfort and that thing that was almost delightful.

Originally published on the Cause of a Kind blog: here

On Building Bad Ideas

Mike Rispoli — Mon, 22 Aug 2022 15:58:03 +0000

As an agency owner, I'm the guy that has to pretend to like your bad ideas. I've heard all ranges of bad ideas. I've listened to a guy trying to sell jarred air from different parts of the world. I've entertained building a play to earn game described as "a total Ponzi Scheme." Some days I hear so many bad ideas I want to hang it all up and close my laptop for good. I'll move the whole family into a Yurt in the woods--never to look at another glowing screen again.

When you own an agency, especially one that builds software, you're going to hear a lot of dreadful ideas. Since you get paid to build things, it behooves you to pretend to like any idea someone is willing to throw money at. You listen, nod, repeat the idea back and why it's good. You then proceed to entertain what it would take to build said idea.

In situations like this, I often return to a quote by David Ogilvy:

"I never assign a product to a writer unless I know that he is personally interested in it. Every time I have written a bad campaign, it has been because the product did not interest me."

He's not saying that the writer must be a user of the product, but the writer should be at least interested in it. This same idea applies to building software. It's going to be difficult to build software that you don't see utility in. While you may not be a user of the software, you should at least believe in its necessity for someone. Building a product without empathy spells doom before you've initialized the repository.

Most of the time, this feeling is subtle. It's rare to hear an outright bad idea. Most of the time they are ideas we don't understand or can't empathize with the problem. These are the ideas that are harder to walk away from. The it's not you it's me of agency pitches. You hate to walk away because you think there might be value in this thing, if only you can understand it.

In these situations it's easy to fall victim to someone's enthusiasm. What you need to ask yourself in these situations is:

How successful is this person going to be at convincing customers to use their solution? Even a great idea has a large chasm to cross when it comes to converting existing behavior. If it solves a pain point, is the existing pain painful enough? Is this a 10x improvement over what exists? Remember, most software doesn't fail because it's poorly built. It fails because it purported to solve a problem that wasn't big enough.

I was once given the advice when hiring, "it's OK to walk away from good people, but it's not OK to hire bad people." When in doubt about a candidate, it's better to walk away than be unsure. I now feel the same way about client ideas. It's OK to walk away from a good idea, but it's not OK to build software on a premise you do not understand.

So if you have an idea that you want an honest opinion on, give me a call. I'll always lend an open ear but I won't give you a price unless I like what you're building.

Originally posted on the Cause of a Kind blog: here

Forem: Mike Rispoli

Land A $195K Job With AI

Chapters:

Installing DaisyUI in Rails without Node.js

Prerequisites

Installation Steps

1. Create Plugin Directory

2. Download DaisyUI Standalone Module

3. Configure Tailwind to Use DaisyUI Plugin

4. Build Tailwind CSS

Using DaisyUI Components

Example: Alert Component

Example: Card Component

Example: Form Components

Available DaisyUI Components

Theming

Automatic Rebuilding in Development

Production Deployment

Precompile Assets

Docker Deployment

Upgrading DaisyUI

Troubleshooting

Issue: "Unknown at rule: @plugin"

Issue: DaisyUI classes not working

Issue: Styles not updating

Issue: Large file size

Comparison: NPM vs Standalone Method

Additional Resources

Setting Up Solid Cache on Heroku with a Single Database

The Problem

Understanding Solid Cache

Why Use a Single Database on Heroku?

Cost and Simplicity

Future Scalability Options

Why Not SQLite for Cache on Heroku?

What I Tried (And What Didn't Work)

Attempt 1: Running the Generator

Attempt 2: Official Multi-Database Setup

Attempt 3: Using db:prepare

The Solution: Migration-Based Approach

Step 1: Configure cache.yml for Single Database

Step 2: Create a Migration for the Cache Table

Step 3: Copy Table Definition from cache_schema.rb

Step 4: Run Migration Locally

Step 5: Keep Development Simple

Step 6: Deploy to Heroku

Verification

Cache Expiration and Cleanup

How Automatic Cleanup Works

Important Characteristics

Why 30 Days for Rate Limiting?

Key Takeaways

Future Migration Path

Additional Resources

Setting up an encrypted secondary drive on Linux

Table of Contents

Introduction

What We're Doing

Prerequisites

Step-by-Step Guide

Step 1: Partitioning the Drive

Step 2: Setting Up LUKS Encryption

Step 3: Creating a Key File for Auto-Unlock

Step 4: Formatting with btrfs

Step 5: Mounting and Setting Permissions

Step 6: Configuring Auto-Mount at Boot

/etc/crypttab (Crypto Tab)

/etc/fstab (File System Tab)

Step 7: Testing the Configuration

Understanding the Final Setup

What You Have Now

Troubleshooting

Drive not mounting at boot

Permission denied when writing to drive

Want to manually unlock/mount

Want to manually unmount/lock

Forgot your LUKS passphrase

Need to add another way to unlock (second key file or passphrase)

Useful Commands

Check drive usage