Willow-Camp on enumerator.dev

willow.camp Updates - October 7, 2025

Tue, 07 Oct 2025 11:25:05 +0000

I’ve spent most of my willow.camp work on finding a new backend language. But I’ve still updated the Rails app! Here’s what’s changed since my last update.

Moved HTML storage out of the post table and into ActionText. It was this deep dive that made me question using Rails. I went down a long rabbit hole, finding a good text editor and then realized this work felt more like building Ikea furniture than I wanted. I’m more interested in having access to the application end-to-end than plugging parts together. Anyway, in the meantime, your posts are now stored in an ActionText table.
Prevented email enumeration attacks by returning an ambiguous error on sign-up. This is my pet peeve with Devise, and I am a bit embarrassed I let this live in production for so long. Previously, the sign-up form would indicate if an email address had already been taken. Since I can’t guarantee people use unique passwords, this means an attacker could use a leaked email/password list to access accounts that use poor password hygiene. No more! I’ve done my best to give ambiguous, helpful messages when something is wrong on the signup page.
Updated dependencies! A whole bunch of Ruby Gems and npm packages got minor version bumps.
Fixed CI errors with vips. This is minor but tests were failing in CI because vips wasn’t installed on the machine.
Cleaned up the Hanami directory. There was a day when I was convinced Hanami was the next framework for willow.camp, and I started a migration in its own directory.
Cleaned up image things I was trying out with images and media handling.

willow.camp: Next

Tue, 07 Oct 2025 01:26:24 +0000

I have spent the past few weeks figuring out the future of willow.camp.

It turns out I love making it, and I love that a handful of people are using it.

I built willow.camp in Rails because I could prototype quickly without having to think about things like auth, logging, or building forms. Rails was great for that.

Now that I have a version of willow.camp I like, I want to be more hands-on with what I’m building, and I find that I’ve spent more time working around the framework and various libraries than I have creating the things I want.

Learning other people’s code isn’t particularly enjoyable.

Aside: Rails and Ruby have also had a public meltdown lately, and I’m tired of feeling like a puny developer watching giants fight and say evil things.

Finding the Next Tech Stack

This was a long journey.

I started with Hanami. It is still Ruby, and the community is much friendlier. Hanami didn’t work for me. It felt like I kept bumping up against the framework, telling me I was doing it wrong. The community is friendly, but the framework is very rigid about “the right way” of doing things.

Then I hopped over to Crystal and tried Lucky, Amber, and Marten. They were all okay to work with, but didn’t strike my fancy.

Lucky was the easiest to get going. I had the data models for willow.camp up and running with a couple of rough-looking views in a few hours.

Marten’s “apps” are nice to work with (think slices in Hanami). But the framework doesn’t natively support subdomain routing, and I didn’t want to fight that design.

Crystal is also very slow to compile. A straightforward Lucky app took over 30 seconds on my M1 to compile! Who has that kind of time when you need to compile multiple times an hour?

Finally, the community. The Lucky devs are really active, which is nice. But Crystal itself seems to have a fragmented community. When I interacted with people, I didn’t really see someone like me in any of the channels.

What I Want in A Language and Framework

An active, welcoming community that builds trust.
Helpful error messages from the language.
Good documentation.

That’s about it. I don’t need huge framework features. I need a language with a helpful design and friendly people.

The Next willow.camp Tech Stack

Once I realized that I valued community and friendly docs more than I valued framework features, I found Gleam.

Backend:
- Gleam with the Wisp Framework on a Postgres database.
Frontend:
- So far, I plan to use Nakai for server-side rendered HTML and HTMX or a similar library for interactive components.

Oh, and I’ve already written a Gleam package! willow.camp needs an accurate domain name parser, so I wrote psl to parse domains using the Public Suffix List.

The Next willow.camp Features

I have a long list of features I want to build for willow.camp, and it’s these features that inspired me to change the language and framework.

A WYSYIG editor that supports markdown. This is the best of both worlds and opens willow.camp up to non-technical writers.
An image library via openverse with an image editor UI.
Email newsletters! I’m excited about this one. You will be able to collect a list of subscribers and send blog posts to your distribution list.
ATProto and ActivityPub support.
An RSS reader so you can follow blogs without a social profile.
Private bookmarks with notes and highlights.

willow.camp Updates September 21, 2025

Sun, 21 Sep 2025 12:58:00 +0000

Quiet on the updates this week. I could rename “Major Features” to “Major Worries” because I’ve spent more time worrying about how images should work than testing them with real users!

I enabled image uploads on the marksmith text editor this week, and a few people tested it out for me. Turns out marksmith doesn’t work how I thought it would with images. Image uploads are still enabled, but I’m going back to the drawing board with the editor UI and media management.

Major Features

Image storage and processing functionality with Active Storage integration, direct uploads, and automatic image processing
I heard you like willow.camp. How about deleting willow.camp? You can now delete your blog and account if you’d like. This will delete all your data and is irreversible. The option is there if you need it.

Improvements

Enhanced navigation to only show blog title or subdomain in menu
Updated testing configuration for quieter pre-commit output
Removed social_share_image functionality

Security & Dependencies

Updated JavaScript dependencies
Updated Ruby gem dependencies
Added new license file

How Much does it Cost to Run willow.camp?

Sun, 21 Sep 2025 12:21:00 +0000

I recently enabled image uploads in the marksmith text editor on willow.camp. I’ve been hesitant to add media management to willow.camp for two reasons: it is hard to get the user experience right, media management adds extra cost.

I am being cost-conscious on willow.camp because it doesn’t make any money. This is a passion project, and I’m having lots of fun doing it. But the more fun I have, the more it might cost.

It turns out adding storage is way cheaper than I thought. I would have to have a whole lot of media and a few really busy willow.camp sites to start getting charged more for data transfer fees.

I will eventually build a pricing plan for willow.camp to cover costs for active sites. In the meantime, if you want to support willow.camp, you can send me a tip on https://ko-fi.com/cassiascheffer.

Claude Code

I include Claude Code in here because it is part of my development process. I’m on the Max plan, and I use it enough that it pays off.

In the past 30 days, I’ve used CAD $188.49 of tokens, and I even took a week off in the woods.

I use Claude Code to scaffold ideas, experiment with features, and improve test coverage. I’ve been able to build willow.camp so quickly because Claude Code is pretty good at scaffolding a blog in Rails.

August Breakdown

service	fee (CAD)
DigitalOcean Droplet (1 vcpu, 1 gb memory)	$8.25
DigitalOcean Postgres ( 1gb ram, 10 gb disk)	$20.82
Hatchbox.io Deployments	$14.13
Claude Code Max	$158.2
Honeybadger Error Tracking	$0
Total	$201.40
Total without Claude Code	$43.20

September Estimate

Here is my estimate for September based on today’s exchange rate.

service	fee (CAD)
DigitalOcean Droplet (1 vCPU, 1 GB memory)	$8.26
DigitalOcean Postgres ( 1 GB RAM, 10 GB disk)	$20.87
DigitalOcean Spaces (half a month)	$3.44
Hatchbox.io Deployments	$14.13
Claude Code Max	$192.84
Honeybadger Error Tracking	$0
Total	$239.54
Total without Claude Code	$46.70

Photo by StellrWeb on Unsplash

willow.camp Updates September 7 2025

Mon, 08 Sep 2025 00:20:35 +0000

It’s been a busy month! I took some time off for a much-needed vacation and forgot to post about willow.camp. I’ve worked on some fun features in the past few weeks.

New Features

Favicons now use OpenMoji emojis! I think these are adorable icons. I have a few qualms with how they fit in the willow.camp design (they’re all a little bottom-heavy), but it’s not a deal breaker.
New favicon picker! You can now search for an emoji by name to pick for your blog.
Now you can have two blogs! You can click on the profile icon and add a second blog. I’m going to use this to document my garden and remind myself what I want to do next year.

I also fiddled around with auto-generating OG images for each blog. I wrote a script that uses your OpenMoji favicon and your blog’s colours to create an Open Graph image for your blog.

Here’s what the tiled image looks like for enumerator.dev.

Ultimately, the best approach for images is to enable users to upload them instead of doing some clever auto-generation. I’m going to put this on my project board and figure out how to do it. Since storage costs me, I might need to change the license on willow.camp and start charging for image uploads.

Here is the Claude-generated summary of the last few weeks.

Summary - August 17 - September 7, 2025

Major Features

Multi-Blog Support: Complete implementation of “Two Blogs per User” feature (#85) - Major architectural change allowing users to have multiple blogs instead of a single-tenant structure
OpenMoji Favicon System: Implemented comprehensive emoji favicon selector with search functionality using OpenMoji library (2d13fd2e)

Improvements

OG Image Generation: Added automated Open Graph image generation scripts (29ba2359, 290f2372)

willow.camp Updates August 16, 2025

Sat, 16 Aug 2025 12:32:00 +0000

It felt like a quiet week on willow.camp but somehow I still got lots done.

Aside from the release notes below, I’m focusing my energy on getting proper favicons for willow.camp blogs.

My first version of this will use OpenMoji emojis for favicons. I like their simple design principles and especially like that they are CC-BY-SA 4.0, similar to willow.camp’s source code.

Here’s how I think I’ll approach this:

Include OpenMoji assets in the willow.camp source code.
Use their source map to populate a choices.js dropdown on the settings page.
Then save the Unicode reference to the database and use that to fetch the correct favicon files when rendering a page.

OpenMoji provides pngs in two sizes, so I’ll need to resize them for the best cross-device compatibility.

Okay, on to this week’s summary!

Improvements

Migrated system tests from Selenium to Cuprite for better performance and reliability
Optimized ReservedWords with Set data structure for faster lookups
Added post-deploy script to send deploy messages to Discord

Security & Dependencies

Updated Rails from 8.0.2 to 8.0.2.1
Updated ActiveRecord from 8.0.2 to 8.0.2.1
Updated Pagy from 9.3.5 to 9.4.0
Updated solid_cable from 3.0.11 to 3.0.12
Updated Honeybadger from 6.0.4 to 6.0.5
Updated Jbuilder from 2.13.0 to 2.14.1
Updated CommonMarker from 2.3.1 to 2.3.2
Updated Lefthook from 1.12.2 to 1.12.3
Updated GitHub Actions dependencies (actions/checkout v4→v5, browser-actions/setup-chrome v1→v2)
Implemented subdomain validation and bot protection in Rack::Attack
Added user agent and IP logging to Honeybadger error context to better understand bot behaviour

Bug Fixes

Fixed deprecated :unprocessable_entity status code (replaced with :unprocessable_content)
Temporarily disabled auto-save functionality. This isn’t a bug fix. Sorry! I want to get to fixing this soon.
Remove social_share_image JavaScript and HTML. I am going to sit on this a bit. I want this to be rendered server-side instead of in the browser. Once I integrate OpenMoji, this will be much easier because I’ll have png assets available on the server.

End To End Tests with Minitest and Rails

Wed, 13 Aug 2025 22:27:26 +0000

willow.camp has a small system test suite that runs on CI. It used to use the out-of-the-box settings that come with Rails: Capybara, Selenium, etc.

I noticed a flaky test on CI, which launched a journey to replace Selenium with Cuprite.

Fixing the Flaky Test

I worked through the flaky test with Claude Code, and as Claude was running the tests, I noticed this pop-up from Chrome.

A data breach on a site or app exposed your password…

I don’t use Chrome very often, so this jumped out at me. Of course, I use the oh-so-secret password “password” in my test suite, and Chrome flagged it as unsafe.

Disabling password leak detection fixed this for me.

browser_options: { "disable-features": "PasswordLeakDetection" }

But I still got timeouts on CI that looked like the tests were running before the browser was ready.

Waiting for CI is a bit painful. You can see my hilariously bad Git history with Claude’s gleeful overconfidence:

* 0c514d1 - nosandbox (15 minutes ago) <Cassia Scheffer>
...
* 57ac55b - bump timeout to 30 sec for ci (21 minutes ago)
* 9d6e86e - rewirite cuprite/capybara configs (26 minutes ago)
* 39f3238 - fix: simplify Cuprite configuration following best practices (10 hours ago)
* 68bfd53 - fix: simplify Cuprite configuration and fix CI timeout issues (24 hours ago)
* cebfae7 - fix: resolve Cuprite websocket timeout issues in CI (24 hours ago)
* dc288b7 - fix: make Cuprite configuration more robust for CI environments (24 hours ago)
...
* e5bb4df - fix: increase Cuprite timeout and add CI-specific settings for GitHub Acti>
...
* cb36eaa - feat: migrate system tests from Selenium to Cuprite (35 hours ago)
* 39f0ff1 - disable selenium chrome password detection (35 hours ago)

That Looks Bad, Cassia. Why Would You Let Claude Do That!?

Because Claude is faster at making mistakes than I am, and I am tired of waiting for CI. Making mistakes quickly means speedier feedback. So I sent Claude off on a fool’s errand to help me learn from the mistakes I would otherwise have made myself.

In the meantime, I read the Evil Martians article about better system tests.

Using Cuprite in Rails with Minitest

The Evil Martians article on system tests uses RSpec, but willow.camp uses Minitest. Here’s what I had to change to make it work with Minitest.

1. PrecompileAssets becomes a module and gets called when setup runs.

# Precompile assets before running tests to avoid timeouts.
# Do not precompile if webpack-dev-server is running (NOTE: MUST be launched with RAILS_ENV=test)

module PrecompileAssets
  def self.setup
    # Check if we're running system tests by looking at the test files being loaded
    running_system_tests = caller.any? { |line| line.include?("test/system") } ||
      ARGV.any? { |arg| arg.include?("test/system") } ||
      ENV["RAILS_TEST_TYPE"] == "system"

    unless running_system_tests
      puts "\n🚀️️  No system test selected. Skip assets compilation.\n"
      return
    end

    puts "\n🐢  Precompiling assets.\n"
    original_stdout = $stdout.clone

    start = Time.current
    begin
      $stdout.reopen(File.new(File::Constants::NULL, "w"))

      require "rake"
      Rails.application.load_tasks
      Rake::Task["assets:precompile"].invoke
    ensure
      $stdout.reopen(original_stdout)
      puts "Finished in #{(Time.current - start).round(2)} seconds"
    end
  end
end

# Run the setup when this file is loaded
PrecompileAssets.setup if defined?(Rails)

2. BetterRailsSystemTests Becomes a Moduel

module BetterRailsSystemTests
  # Make failure screenshots compatible with multi-session setup.
  def take_screenshot
    return super unless Capybara.last_used_session

    Capybara.using_session(Capybara.last_used_session) { super }
  end
end

3. Modules are included in ApplicationSystemTestCase

require "test_helper"
require "capybara/cuprite"
require_relative "system/system_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  include BetterRailsSystemTests
  include CupriteHelpers

  driven_by Capybara.javascript_driver

  def setup
    super
    # Use JS driver always

    # Store original host for cleanup
    @original_host = Rails.application.default_url_options[:host]
    # Make urls in mailers contain the correct server host.
    # This is required for testing links in emails (e.g., via capybara-email).
    Rails.application.default_url_options[:host] = Capybara.server_host
  end

  def teardown
    # Restore original host
    Rails.application.default_url_options[:host] = @original_host
    super
  end
end

Flakiness Still Included on CI

I still see a bit of system test flakiness on CI, but far less than before. I am running on the default GitHub Actions runner, which is pretty small. So there’s a good chance that the flakiness is due to low resources on the machine. So far, tests have consistently passed when I run these on my M1 MacBook Air.

I’ll dig into these flaky tests another day! But this looks like an improvement overall to me!

willow.camp Release Notes August 9, 2025

Sat, 09 Aug 2025 20:51:00 +0000

Really quiet week for willow.camp this week.

I updated a few dependencies and upgraded the server it runs on. Everything’s been running smoothly!

I’ve also been working with an LLM to learn Hanami and might eventually move the backend over to Hanami. I’d lose a lot of “batteries included” stuff switching to Hanami, but I like the philosophy they have.

It’s been nice working on something the LLM doesn’t know well. It often drifts off into Rails land, and I have to learn the right pattern to correct the LLM. I think I learn faster this way because it’s easier to be skeptical of the LLM than it is of my own mistakes.

Please have a look at my first pass at the migration at the willow_camp_2 repo.

willow.camp Release Notes Week Ending August 2, 2025

Sat, 02 Aug 2025 12:43:00 +0000

It was a quiet week for willow.camp. The biggest thing I did was to test out generating Open Graph images using a browser canvas. I also improved logging for Honeybadger Insights, which will help me find performance issues.

Beta Features

Added a beta feature for auto-generating Open Graph images for RSS feeds and social media. I’m still figuring out how I want this to work before releasing it for general use.

Improvements

Added in-memory caching to the blog index page.
Site map generation performance optimizations and test coverage.
Added a few more Rack::Attack configurations for noisy bots.

Infrastructure & Monitoring

Logging Refactor to work better with Honeybadger Insights.
Marksmith Editor: Fixed scroll position issues during autosave.

Testing A New willow.camp Feature

Wed, 30 Jul 2025 13:12:00 +0000

I don’t like competing for clicks. But I do like people reading my blog.

If you landed here form LinkedIn, you probably saw a colorful image showing the title of this post. Where is that image?! It’s in the Open Graph tags in the head of this page.

When I launched willow.camp, I intentionally kept social-media style features out of it. willow.camp doesn’t track views (aside from what’s needed for performance and bug monitoring), and doesn’t have likes or comments.

But it was missing something.

When I shared posts to LinkedIn, my posts would show up as plain text. Despite having no analytics, I get the feeling that some people miss my posts because they are overwhelmed by a sea of images.

So here I am. Writing a social media feature for willow.camp that is in beta (meaning I am the beta tester!) If you are using willow.camp, I’ll release this feature once I’ve put the right polish on it.

I added a canvas to the post editing interface that grabs the theme colours, favicon, and title to create an Open Graph image that LinkedIn can see. This is the first time I have image storage.

The images are stored locally on the server, so I’ll run out of space one day. But for now, I’m going to test this out and polish up the user experience before making it more broadly available.

willow.camp Release Notes Week Ending July 26, 2025

Sat, 26 Jul 2025 12:20:00 +0000

Here’s everything I did on willow.camp this week. It blows my mind how much I can get done when I’m having fun! I work on this app for about an hour every morning and evening.

Major Features Added

Featured posts functionality with toggle UI
Tap/click to edit a tag on the tags index page
Terms of Service page
Rack-attack integration for rate limiting and security (blocking PHP requests, credential probes)
Added no-index option to settings page for search engine control

UI/UX Improvements

Replaced inline SVG icons with heroicons gem
Enhanced mobile navigation by moving dashboard tabs to the hamburger menu
Updated tag UI with circular icon buttons
Replaced default Rails error pages with custom DaisyUI designs
Improved post actions UI with a dropdown menu and a modal delete confirmation
Added “Save Draft” and “Publish” buttons instead of a “Published” checkbox

Performance & Testing

Optimized Dashboard::TokensControllerTest (1.97s → 0.31s)
Optimized slow mermaid test by reducing markdown content in tests
Added Bullet gem for N+1 query detection
Fixed N+1 query in API posts controller
Re-enabled parallel test runs

Code Quality

Removed RuboCop entirely and only use StandardRB for code style
Added standard-rails gem for enhanced Rails linting
Updated Brakeman from 7.0.2 to 7.1.0
Merged willow_camp_cli history into cli/ subdirectory

Security & SEO

Enhanced request logging with user agent and subdomain info
Added CC license to GitHub repo

Bug Fixes

Fixed favicon controller error
Fixed mobile tag editing card UI updates
Fixed OG published_time tag for draft posts
Prevented mobile auto-capitalization for domain inputs

Use Precomputed Hashes Instead of BCrypt in Test

Mon, 21 Jul 2025 00:55:00 +0000

I asked Claude to find the slowest test file again after my success earlier today and Claude found a call to BCrypt in my fixtures that was gobbling up time.

I need user records all over the place in my test and each new user is a new call to encrypt a password.

Here is Claude’s summary, with my Grammarly edits:

Problem: The PreviewsControllerTest#test_should_show_preview_for_own_unpublished_post test was taking 2.95 seconds due to BCrypt password hashing being computed dynamically in fixtures with <%= BCrypt::Password.create("password") %>.

Solution: Replaced the dynamic BCrypt computation with a pre-computed hash $2a$12$dapdHZiOTxAL8OT9yNI6e.hhTjRhWgXq7kx737/xf8tBfQbMD2bi for all user fixtures.

Result: The slowest test now runs in ~0.25-0.52 seconds (82% improvement) and all tests pass. The overall test suite performance has been significantly improved, as this optimization affects all tests that use user fixtures.

willow.camp Release Notes Week of Jul 19

Sun, 20 Jul 2025 18:13:00 +0000

Features Added

Live markdown preview functionality using “Preview Post” button at the bottom. This is better than the Marksmith “Preview” beside “Write” because it shows the rendered site.
Automatic dark mode detection for Marksmith editor which is better than before but still needs work
Enhanced tag selection using the Choices.js library. Yay! I learned something about importing and CSS variables here. I’ll write a post on this soon.
API documentation link added to settings page.
Post footer feature with conditional display (hidden on about page). Find this on your settings page.
Tag functionality with tag counts and improved UI. I still want to work on this a bit.

Thanks to Mark for a few of these suggestions!

Bug Fixes

Draft post handling - Skip OG published_time tag for draft posts and allow nil dates
Colour fixes for UI elements
Landing page navigation - Fixed redirect behaviour when logged-in users visit the home page
Production optimization - Conditionally preload the app only in the production environment, fixes dev env hanging sometimes.
JSON error handling - Return 404 for JSON requests to non-existent resources
Accessibility updates for blog interface and voiceover support. Feedback please! I’m new to a11y and would love to know how to make this better.

Performance & Maintenance

Test optimization - Reduced markdown content in slow Mermaid tests
Parallel testing is temporarily disabled for stability (on my machine ☹️)
Security update - Brakeman updated from 7.0.2 to 7.1.0
Code quality - Multiple linting fixes applied
Documentation - Added CLAUDE.md project instructions

Speeding Up willow.camp's post_test.rb by 99%

Sun, 20 Jul 2025 14:05:00 +0000

I just asked Claude to speed up the slowest test file in willow.camp. post_test.rb was taking over 1 second to execute. For a tiny Ruby app, that’s a long time.

Here’s what Claude did. I was not expecting such a simple fix!

Test: test_should_detect_mermaid_diagrams_and_set_has_mermaid_diagrams_flag in test/models/post_test.rb:82

Issue: The test was using an unnecessarily large markdown string that required expensive processing through the Commonmarker library.

Optimization: Reduced the test markdown from a multi-section document to a minimal string that still tests the same functionality:

Before: Large heredoc with headers, multiple code blocks, and text content

After: Simple “mermaid\ngraph TD\n A --> B\n” string Performance Improvement:

Before: 1.31 seconds

After: 0.01 seconds

Improvement: 99%+ faster (130x speed improvement) The optimization maintains full test coverage while dramatically reducing execution time by eliminating unnecessary markdown processing overhead.

The original test was designed to evaluate a full-fledged Markdown document that was about 10 lines long. I didn’t need that in this case because I just needed to test that my custom mermaid code block worked.

Thanks Claude!

How to Migrate Data From One Postgres Instance to Another

Thu, 03 Jul 2025 00:57:00 +0000

My first version of willow.camp ran a Postgres instance on the same container as the app. Before going to production, I had to migrate the data from the local Postgres instance to the managed instance.

I had a whopping 50-some records in the database. So, of course, could have used the willow_camp_cli to migrate them, but I wanted to do it the hard way. Because sometimes the hard way is fun. At least, it’s fun when it’s much lower stakes than working on a large production app.

Here is how I migrated the data from one database to another using an SSH tunnel, pg_dump and pg_restore.

Maintenance Mode

I had all of two real-life users when I did this. So I didn’t need maintenance mode, but I went ahead and used it anyway. hatchbox has a maintenance mode toggle in the UI that I turned on.

Set Up a New User

Digital Ocean sets up a managed database with a root user. I wanted to create an app-specific user with access to the necessary databases.

I connected to the managed database using psql and created a user, granting the necessary permissions.

PGPASSWORD=CLUSTER_PASSWORD psql \
  -U cluster_admin \
  -h digitaloceanhost.com \
  -p 25060 \
  -d defaultdb

CREATE USER "willow-camp" WITH PASSWORD 'NEW_PASSWORD';

-- Grant connect permission to the database
GRANT CONNECT ON DATABASE defaultdb TO "willow-camp";

-- Grant usage on the schema
GRANT USAGE ON SCHEMA public TO "willow-camp";

-- Grant table permissions (choose what you need)
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO "willow-camp";

-- Grant permissions on sequences (for auto-increment/serial columns)
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO "willow-camp";

-- Grant permissions on future tables (optional)
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "willow-camp";
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT USAGE, SELECT ON SEQUENCES TO "willow-camp";

Export Data from the Old Database

To do this, I created an SSH tunnel to the hatchbox instance that hosted my app and database. Then, I used pg_dump to export the data. -L in the command below sets up port forwarding so that my local port 5432 points to the hatchbox server where Postgres is running.

ssh -L 5432:localhost:5432 deploy@10.0.1.100

Then I created a pg_dump on my local machine through the tunnel. Note that localhost:5432 now points through the tunnel to the hatchbox database.

pg_dump -Fc "postgresql://app_user:PASSWORD@localhost:5432/myapp_production" > myapp_primary_20250625_185627.dump

Import Data to the New Database

I made a common mistake here. A pg_dump file includes statements like ALTER TABLE public.ar_internal_metadata OWNER TO user_a1b2c3d4e5f6;, which assigns ownership of a table to a user, but this user only existed in my hatchbox database.

I worked around ownership issues by using the --no-owner and --no-priviliges options.

PGPASSWORD=CLUSTER_PASSWORD pg_restore \
  -U cluster_admin \
  -h digitaloceanhost.com \
  -p 25060 \
  -d defaultdb \
  --no-owner \
  --no-privileges \
  -v \
  myapp_primary_20250625_185627.dump

Verify the Data

Once pg_restore had done its job, I connected to the new database again using the psql command above and issued a few queries to check the data.

SELECT relname as table_name, n_live_tup as current_rows FROM pg_stat_user_tables ORDER BY current_rows DESC;

Connect the App to the New Database

Finally, I updated the database environment variables in hatchbox, which rebooted the app. I performed a quick rails console check to ensure the database was connected, then I took the app out of maintenance mode.

Once the app was back up, I could see queries hitting the managed instance in the DigitalOcean UI, and I tore down the old database on my hatchbox server.

Should I use a Managed Postgres Instance?

Tue, 01 Jul 2025 13:04:00 +0000

I asked myself this question while developing willow.camp and decided to use a managed instance before sharing willow.camp with the world. In this post, I’ll explain my thought process and how it changed as I finished off willow.camp’s blogging features.

Hatching a New App

Once I had a rough version of willow.camp coded up, I wanted to deploy it so that I could test features like subdomains, multiple users (real people, not just me and some database seeds), and eventually custom domains.

I kicked off a new app on hatchbox.io using DigitalOcean. hatchbox wires everything up to deploy a Rails app off the main branch of a GitHub repository. All I needed was a database, so I clicked “PostgreSQL” in hatchbox, so that my Rails app and database would run on the same server. In just a few clicks, willow.camp was up and running with 1 vCPU, 1 GB of RAM, and 25 GB of storage.

Going to Production

Once I had most of the features I wanted, I had to make a decision. What do I do if my server crashes? The environment and data are ephemeral. It is easy enough to get the web app up and running again, but I’d lose all the data in my database.

My requirements for the database were:

Automated backups at a minimum in a daily interval. Despite making willow.camp for markdown, I end up saving drafts right in the UI.
Access to backups for a limited period. I don’t need much more than two or three days of backups.
Preferably, minimal configuration.

I had three options:

Take periodic snapshots of the server that I can restore in case of data loss. I didn’t see an automated way to take snapshots, so I dropped this from the list.
Mount a storage volume: This would separate the storage from the container on which my app was running. This seemed like an okay option to me but I was also wary of managing a single server with the Rails app and Postgres.
Use a managed Postgres instance: This met all my requirements, but it cost a bit more. I waffled on this and decided to go with it in the end.

Why I Chose a Managed Postgres Instance

In the past, I worked on a production app where the app and database were hosted on the same server. It constantly felt like a precarious situation. The database and the app server were competing for resources.

On willow.camp I only have 1 vCPU and 1 GB of RAM. I could upsize my droplet, but then I’d lose sleep over balancing resources between the two fundamental processes that run the app.

willow.camp is a tiny app and can easily run with the Rails app and Database on the same small server. I wouldn’t need to lose sleep over it, but I’d be thinking about it all the time.

I needed peace of mind that the processes would keep running and my data would be safe. Scaling up a single instance to handle the app and database didn’t sound like a fun hobby for me. It certainly wasn’t a fun job when I worked on the production setup like this in the past.

The resources on this instance are ideal for a small Rails app. With 1 vCPU and 1 GB of RAM, I can run 5 Puma threads. My response time is well under 200 milliseconds (often under 100ms), so it’ll be a while before I need to consider another CPU.

Choosing a managed Postgres instance gave me peace of mind that my data was safe, my app server and my database had isolated resources, and I had the flexibility to change the app server without affecting the data. The extra $10 a month simplifies my tiny infrastructure and lets me focus on the fun parts of willow.camp.

Why “willow.camp”

Mon, 30 Jun 2025 12:25:59 +0000

In my last post I forgot to explain the name “willow.camp.” It’s quite simple. We have a very cute dog named Willow and I thought I’d name this cute blogging service after him and “camp” was a great TLD that made me think of setting up camp and reading a good book.

Like a base camp, willow.camp is a good place to stash your stuff. Right now you can stash your writing here. In the future, you can stash bookmarks and RSS feeds.

The Naming Journey

I really wanted willow.blog at first, but .blog was a bit to pricy for a side project. willow.page sounded nice but it was too similar to another great blogging service, pika.page.

I spun the idea around for a while. I even got willow.camp deployed on hatchbox and it was still named willow.blog.

I finally settled on willow.camp because I realized I wanted to make an RSS reader and bookmarking service too, and willow.camp sounded like a nice place to stash things.

So, long story short, willow.camp is named after a cute dog named willow.

Introducing willow.camp

Sat, 28 Jun 2025 20:06:00 +0000

I’ve been working on a side project and am finally ready to share it! My blog, enumerator.dev, is now hosted on my platform called willow.camp.

willow.camp started because I wanted a platform that felt like me. I wanted a simple editing interface, the ability to import and export every post in markdown, and a pared-down reading interface.

My blog was previously hosted on Ghost, but the experience felt like an “influencer” blog to me. I’m a regular developer sharing the projects I work on, and I don’t need a big newsletter distribution list or metrics on open rates.

I looked at bearblog.dev and pika.page as alternatives to Ghost. They are both lovely platforms, and willow.camp is inspired by them, but they didn’t quite meet my needs. So I took the plunge and typed rails new willow_camp in my terminal.

Well, okay, I admit. First, I tried Elixir; then I read about doing it in Rust and tested out Hanami before realizing that I wanted to create something more than I wanted to learn a new language.

Sometimes speed is about using a batteries-included framework more than it is about milliseconds of server render time.

The willow.camp Stack

willow.camp is built on Rails 8, Turbo, Hotwire, Stimulus, and DaisyUI. These libraries have made it easy to spin up scaffolding and prototype ideas. A considerable part of the initial commits in willow.camp are all rails scaffold (not even AI!). As things took shape, I polished off features using context7 to pull docs into Zed hooked up to GitHub Copilot.

So far, here are a few libraries I’ve used to develop willow.camp:

acts-as-taggable-on for tagging posts.
marksmith for a markdown editing UI.
commonmarker for parsing and rendering markdown.
front_matter_parser for parsing YAML front matter on markdown files.
friendly_id for post slugs.
pagy for pagination.
public_suffix for validating custom domains without a complex regex.

Hosting

willow.camp is hosted on a DigitalOcean instance with a managed Postgres database. Deployments and configs are managed through hatchbox.io.

APM, Errors, Emails

I hooked up Scout Monitoring for APM and Honeybadger for error tracking. For now, I’m well below the usage limit for both, so I’m on the free plan. I’m happy with both of those, but I find the log management in Scout to be somewhat clunky on my tiny MacBook Air’s screen. I’m not sure I’d pay for the logging aspects of Scout, but everything else meets my needs.

Password reset emails are sent through loops.so. Loops was straightforward to set up, and transactional emails are free.

Dashboard

As mentioned above, the editing interface is marksmith, an easy-to-use, plug-and-play markdown editor with a built-in preview feature. Posts are saved in both markdown and HTML formats. This makes exporting content through the API straightforward because Markdown is the base format in which posts are written and saved. HTML is only used for display.

Mermaid Diagrams

You can add a code block with mermaid as the language, which will render a mermaid diagram on the page in place of the code block. Have a look at How Rack::Timeout Keeps Your App Alive for an example.

Auto-saving Posts

I like to start a draft post, then walk away and think about it. While I enjoy writing in Obsidian, I often use my blog “drafts” as a place to store ideas.

I added a stimulus controller that auto-saves draft posts. It checks if the post is “dirty” (i.e., changed since the last save) and saves it every 60 seconds. You can also hit Command/Control + S to save while you type.

Auto-save is disabled on “published” posts because I wouldn’t want a half-edited post to be saved and published.

No Image Hosting

I don’t host images or static content aside from what’s in the Rails asset pipeline. This is intentional right now. I want to keep hosting complexity to a minimum, and I didn’t want to worry about storage services, mounting volumes, or data retention. For now, I’d like the server to be ephemeral.

Favicons, Themes, Subdomains, & Custom Domains

Of course, I spent the most time on the settings page.

You can preview custom favicons and themes on the willow.camp home page by clicking the menu items in the top right. The themes come from DaisyUI. The favicon functionality still requires some refinement.

How willow.camp (sort of) Generates Favicons

Users can insert any emoji into the “favicon” settings form. The emoji is saved to their settings, and then when the page loads, it is rendered in in-memory canvases to generate the various sizes of favicons needed and insert them into the head as an image in a URI scheme like so:

<link type="image/png" rel="icon" sizes="16x16" href="data:image/png;base64,...lots of characters=">

This works for most cases, but since the image doesn’t exist until the JS renders it, some browsers may not display a favicon at all, and there are no Open Graph images available for link previews on social sites.

Better Favicons in the Future

I want to fix the favicon functionality. I think the best way to do this reliably is to pre-generate images for 10-20 emojis that users can pick from. This way, I only have to store a set number of assets on the server and can provide real links to favicon images.

Another possibility is to render a canvas in the browser when the user selects the desired emoji. Then, when they update their settings, save the favicon as an attachment and generate the correct sizes on the server. This would provide flexibility to use any emoji, but it would also require hosting more static content, which I didn’t want to do yet.

Themes

The DaisyUI themes are fun! I borrowed their theme picker HTML and used a Stimulus controller to give instant previews of each theme. Users’ theme preferences are saved in the DB and rendered in the HTML.

I experimented with allowing users to choose between a light and dark theme, but couldn’t get it to work to my satisfaction. prefers-colour-scheme works great with DiasyUI’s default light and dark, but I didn’t see an easy way to pass a user’s preferences from the database into the CSS without compiling the assets on each request.

I did have a light/dark functionality sort of working with a Stimulus controller and some data attributes in the HTML, but there was a brief flash of the default light or dark scheme before the chosen scheme was loaded.

For now, you can pick one colour scheme for your willow.camp blog.

Subdomains and Custom Domains

Thanks to hatchbox’s Caddy setup, subdomains and custom domains are served over HTTPS. Each blog has a subdomain like cassia.willow.camp and an optional custom domain like enumerator.dev. Users point a CNAME record to their subdomain to set up a custom domain name.

SEO

It has been nearly a decade since I had to think about SEO. I’ve added Open Graph tags to the pages, and every site gets a sitemap.xml and robots.txt. I tried to use semantic HTML as best I could and asked Claude to audit the pages.

No Analytics

I had plausible.io on my blog for a very brief period, but the analytics provided too much information for me. I just want to share what I write. I don’t need graphs.

If you want to use willow.camp for your blog and want analytics, let me know, and I can add a feature to let you insert the code you need.

Accessibility

I need to do another accessibility audit on willow.camp. I tried to ensure the HTML used aria labels that were clear and concise.

I recently found CapybaraAccessibilityAudit, which I’ll use to audit the dashboard and public-facing pages.

About Page

The “about” page is a bit of a hack. “Pages” and “Posts” are almost the same thing in the database. I used single table inheritance to create a single “about” page for each user. Every user always has one about page. If you delete your “about” page, a new draft page is created in the background.

willow.camp doesn’t use pages otherwise. Everyone gets one “about” page.

Feeds: RSS, Atom, JSON

RSS and the indie web are having a comeback. I’ve been reading RSS on Feeeed and Feedbin lately, so proper feeds are essential to willow.camp.

My pet peeve with “follow me on RSS” links is that most of the time, you end up downloading a file when you click on the link. That’s not helpful.

I drew inspiration from Subscribe Openly and created a helpful “Subscribe” page with clipboard helpers to copy the feed of your choice easily. Check it out: enumerator.dev/subscribe.

API and CLI

willow.camp comes with an API and CLI tool for managing content. I’ve used the CLI to import and format my content from Ghost.

The CLI converts most of the HTML from Ghost correctly, but leaves some extraneous markdown that requires manual cleanup.

Todo list

I have lots of things I still want to do on willow.camp. Here are a few things I have in mind:

Write an Obsidian extension. I got Claude, Copilot, and Zed to build the CLI in Ruby. It does the job. However, what I’d like is a full-featured Obsidian extension that allows me to write, edit, publish, and sync my blog directly within Obsidian.
Re-implement syntax highlighting in code blocks. I think I messed up code syntax highlighting somewhere along the way. I want to fix this.
Fix the CLI tool’s gem publishing. Something borked here and I haven’t had a chance to fix it. If you want to use the latest CLI, you can build it from the repo for now.
Add a manual “light” and “dark” toggle to toggle between a user’s preferred schemes. This wouldn’t use prefers-color-scheme but would still allow light and dark mode.
Disallow a light scheme to be paired with Dracula because Dracula lives in the dark.

New Features

I love RSS, and I mostly love most RSS readers. But like a blogging platform, I’ve had trouble finding one that fits me. I want to build an RSS reader functionality into willow.camp so you can read RSS in the same place you publish.
Bookmarks! I love everything about raindrop.io, but I also like the challenge of building my own. So why not make willow.camp the super app of the indie web and add bookmarks? I’m joking here. I’d create a bookmarking feature for myself and hope that others will like it too.
Maybe introduce distribution lists? I liked that people could get my posts by email on Ghost. I didn’t want to see the open rates and graphs. I might re-introduce email distribution with a more straightforward UI.

Thoughts on Stimulus, Hotwire, and Turbo

Wow. I love this. Honestly, it makes me love developing web apps again. There is no heavy complexity between the frontend and backend. You don’t need to shift mindsets to start writing in a frontend framework.

I didn’t expect to enjoy these features this much. However, I’m back to writing HTML that maps directly to what I see in the browser, and a few extra bits of syntax in data-attribute fields make it a snappy and dynamic UI.

willow.camp is Free

willow.camp is free to use. If people find it useful, I might introduce a paid tier to cover hosting costs.

If you want a willow.camp blog, you can sign up and try it out.