So the Pi now runs Homebridge, which puts our underfloor heating thermostats (and also now Samsung TVs) in Apple Home. For good measure it also runs Pi-hole, which blocks ads and trackers for every device in the house.
First I checked the cheap parts. SD cards and power supplies fail far more often than the Pis themselves.
In Raspberry Pi Imager, chose Raspberry Pi 4, then Misc utility images → Bootloader (Pi 4 family) → SD Card Boot. Wrote it to the new SD card. Booted the Pi from it and waited 10 seconds. Screen went green!
Flashed the Homebridge Raspberry Pi image with Raspberry Pi Imager. Set the username, password and Wi-Fi in Imager’s customisation step.
http://<ip>:8581 on my Mac.Then, I reserved a fixed IP for the Pi on my router. Pi-hole needs this later, and it makes everything else easier to find. Fixing a bunch of IPs of home-based things is not a bad idea in my experience.
There’s no Homebridge plugin for ProWarm (!) and the regular app can’t talk to anything. However, ProWarm’s app is a rebranded Tuya app.
So the route is ProWarm → Tuya’s own Smart Life app → Homebridge.
I won’t go into the details here: an agent can walk you through the steps, and the thermostats might get replaced anyway if they become more trouble than they’re worth.
The most important note is to keep the schedules on the thermostat, not in the Home app.
I use the Home app for temporary overrides, and for “when everyone leaves, set to 16°C” automations. That kind of change only lasts until the next schedule block. If we’re away, we use the thermostat’s “Holiday Mode”.
Schedules, boost, holiday mode and frost protection all run on the thermostat itself. They keep working if the Pi dies. Homebridge is only for info and temporary overrides.
A word of warning before you start: once your router points at Pi-hole, every device in the house depends on this Pi to look up websites. I got this wrong the first time and the whole house lost Wi-Fi.
Also if the Pi dies, nothing loads, which is why I bought the case detailed later to auto-power the Pi. If I ever need to undo it, I’ll set the router’s DNS back to automatic.
The Homebridge UI has a terminal: top-right menu → Terminal. But it logs you in as the homebridge service user. Plain sudo fails. So I had to switch to my own user (set up in Imager):
su - <username>
SSH from the Mac should also work in theory, but I used the Homebridge terminal.
curl -sSL https://install.pi-hole.net | bash
Then I set the admin password. This is a separate password, for the Pi-hole web page only:
sudo pihole setpassword
The Homebridge image runs nginx on port 80, so http://<ip>/admin showed Homebridge, not Pi-hole. Pi-hole’s DNS was fine; only the admin dashboard couldn’t get the port. So… moved it to 8080:
sudo pihole-FTL --config webserver.port '8080o,[::]:8080o'
sudo systemctl restart pihole-FTL
The admin page is now at http://<ip>:8080/admin.
First I tested on my Mac. In System Settings → Network → Wi-Fi → Details → DNS, I added the Pi’s IP and removed the other entries. Then I browsed a few sites and watched them appear in Pi-hole’s Query Log.
I regret nothing about the levels of Cat6 and the number of UniFi Access Points I own.
My network has a Virgin Media Hub with a UniFi Express behind it, and the UniFi does the routing. Virgin’s Hub won’t change the DNS it hands out, but UniFi will, and my entire house points at the UniFi.
Devices plugged directly into the Virgin Hub, rather than into the UniFi, won’t use Pi-hole.
Checked it worked. Removed the Pi’s IP from the Mac’s manual DNS settings, so the list was empty. Then turned Wi-Fi off and on and ran:
scutil --dns | grep nameserver
It listed only the Pi’s IP. That proves UniFi is handing it out. If you skip removing the manual entry, the check only shows the setting you typed in yourself.
To undo, set DNS Server back to Auto.
Pi-hole ships with Steven Black’s list. I added:
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/pro.txthttps://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/tif.medium.txthttps://adguardteam.github.io/HostlistsRegistry/assets/filter_7.txthttps://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/whitelist-referral-native.txtAdded each one under Lists, then ran Tools → Update Gravity.
I kept the default Steven Black list too, because Pi-hole removes duplicate domains when it builds the lists.
I looked at Steve Jenkins’ Pi-hole list of lists. It’s 21 blocklists, including the ones I added. His regex file allows things for his household (Hulu, USPS, Roku, CrossFit), and blocks patterns like ^analytics, ^stats and ^aff that might break legitimate sites. I want to minimise “home tech support”, so I took the Smart TV list and the referral allowlist and left the rest.
When something breaks, usually a shopping link or an email click-tracker, I find the blocked domain in the Query Log and click Allow.
I don’t want to manage this actively.
Blocklists already update weekly on their own. Pi-hole runs the job from cron.
Turned on unattended upgrades:
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
HaGeZi updates its lists several times a day. Pi-hole only fetches them weekly. So I fetch them every day:
echo '15 5 * * * root PATH="$PATH:/usr/local/bin" pihole -g >/var/log/pihole/gravity-daily.log 2>&1' \
| sudo tee /etc/cron.d/pihole-gravity-daily
The manual update is:
pihole -up
I run it from cron at 4:30am on the 1st of each month:
echo '30 4 1 * * root PATH="$PATH:/usr/local/bin" pihole -up >/var/log/pihole/autoupdate.log 2>&1' \
| sudo tee /etc/cron.d/pihole-autoupdate
Installed Homebridge Updater (@homebridge-plugins/homebridge-updater). It used to be called Homebridge Plugin Update Check. Every auto-update option is off by default.
Turned on:
Set Sensor Type to Contact Sensor and turned on notifications for it in the Home app. It tells me when updates are waiting, and when an automatic one fails.
Once it was all running, I moved the Pi into a fancy case. It restarts after power loss, cools the board and attaches an SSD through USB.
Had to run Argon’s script as my own user, using su as above in the Homebridge terminal:
curl https://download.argon40.com/argon1.sh | bash
Now the power button works.
SD cards wear out under constant writes, and Pi-hole writes logs all day. So I cloned the SD card onto the SSD.
Backed up Homebridge and Pi-hole.
Updated the bootloader:
sudo rpi-eeprom-update -a
Installed Jeff Geerling’s maintained fork of rpi-clone:
curl https://raw.githubusercontent.com/geerlingguy/rpi-clone/master/install | sudo bash
Cloned, answering yes to the prompts:
sudo rpi-clone sda
Set USB boot first: sudo raspi-config → Advanced Options → Boot Order → USB Boot.
Powered off. Took out the SD card and pressed the power button. Ran findmnt / to check it showed /dev/sda2.
I’ve now plugged the Pi directly into the UniFi router and turned off Wi-Fi, reserving the IP address of the wired connection and using that as the DNS server.
]]>LIKE or ILIKE query, user input can change the pattern. A search for 100% returns every row containing 100. A bare % returns the whole table. Active Record’s sanitize_sql_like fixes this.
…dropping the user’s term straight into the pattern:
class Article < ApplicationRecord
scope :containing_text, ->(query) {
where("articles.title ILIKE :q", q: "%#{query}%")
}
end
Article.containing_text("100%") # also matches "100 days of Rails"
Article.containing_text("snake_case") # also matches "snake-case vs kebab-case"
Article.containing_text("%") # matches everything
…sanitize_sql_like around the term, before you wrap it in your own wildcards:
class Article < ApplicationRecord
scope :containing_text, ->(query) {
where("articles.title ILIKE :q", q: "%#{sanitize_sql_like(query.to_s)}%")
}
end
Article.containing_text("100%") # "Reaching 100% coverage", not "100 days of Rails"
Article.containing_text("snake_case") # "Why snake_case wins", not "snake-case vs kebab-case"
Article.containing_text("%") # titles with a literal %, not everything
LIKE has three special characters: % matches any run of characters, _ matches exactly one, and \ escapes the other two. A bind parameter protects the SQL statement, but it passes these characters through untouched.
sanitize_sql_like puts a backslash in front of each %, _ and \, so they match literally:
Article.sanitize_sql_like("100%") #=> "100\\%"
Article.sanitize_sql_like("snake_case") #=> "snake\\_case"
Article.sanitize_sql_like("c:\\tmp") #=> "c:\\\\tmp"
Postgres and MySQL use \ as the escape character by default. SQLite has no default, so add an ESCAPE clause and pass the same character to sanitize_sql_like:
where("articles.title LIKE :q ESCAPE '!'", q: "%#{sanitize_sql_like(query.to_s, "!")}%")
Call .to_s on the input. sanitize_sql_like calls string methods on its argument, so it raises NoMethodError on nil. A blank search then becomes %% and matches every row. To return no results instead:
scope :containing_text, ->(query) {
return none if query.blank?
where("articles.title ILIKE :q", q: "%#{sanitize_sql_like(query)}%")
}
Escape the term before adding your own wildcards. "%#{sanitize_sql_like(query)}%" keeps the outer % as wildcards and escapes the inner ones. sanitize_sql_like("%#{query}%") escapes your wildcards too, so it only finds titles that contain a literal % either side of the term.
This method has been public API since Rails 5.2. Use it alongside the bind parameters from not interpolating strings into Active Record. Search your app for LIKE and ILIKE to find the queries that need it.
If no user input reaches the pattern, you don’t need it. A hardcoded where("path LIKE 'admin/%'") is fine.
Some tools let users type % on purpose, such as an internal admin search. Escaping breaks that. Tell users in the UI whether wildcards work.
A leading % stops the database using a normal index, so every search scans the whole table. On Postgres, a pg_trgm GIN index on the column can help.
sanitize_sql_like is for LIKE and ILIKE only. Postgres full-text search with to_tsquery has its own syntax to sanitize, and pg_search handles that for you.
Arel’s matches can also write the ESCAPE clause for you:
where(arel_table[:title].matches("%#{sanitize_sql_like(query.to_s)}%", "\\"))
I’ve been considering David’s opening Rails World keynote and realised that this is the main problem I have with it. Rails World is about “shaping the future of Ruby on Rails”. Instead what we got was opinionmaxxing: a lot of certainty about the destination, but in his own words, not much that was ‘practical’ or ‘prescriptive’ about getting there.
There’s a vibration of uncertainty in our community and the wider industry, even from folks, like me, who were early to playing with and then using the new LLM-powered coding tools and harnesses for real production work.
I was left with a “what’s the point?” feeling. I don’t believe this was the intention. I think David meant it as a provocation, to jolt the room. But the room was already there: when he polled the audience only five people out of 1,200 were still writing material amounts of code by hand. He seemed surprised at the scale of that. He shouldn’t have been, the Rails community are tinkerers, early adopters and pragmatists.
To be clear I think he’s directionally right on software. The way we make software has changed forever. Yesterday I shipped (and reviewed) 21 bug fix PRs to CoverageBook, upgraded a Rails app from 7.x and Tailwind 2 to latest versions and shipped a couple of feature PRs. I’m engaging more judgement on how much I code review when I can verify in other ways. I’ve never been so able to deliver well-made software, so fast.
I do believe however there’s a lot of interesting work to do in step 2. Software engineering has always been more than typing code. I’m not seeing evidence I can abdicate my taste to Anthropic, OpenAI or the fast-following open-weight models.
There were multiple version numbers mentioned in the keynote: all LLMs, not a single mention of Rails 8.2.
David’s attention is elsewhere. Ruby was “about 3%” of his work this year, and he’s “talked about nothing else but Omarchy for about 3 months.” Now the models can one-shot a calculator and convert existing applications to Rust. He seems uninterested in the useful guardrails, determinism and token efficiency1 that a battle-tested framework can provide when using agents.
He did concede, on the panel the next day, that he’d still spin up Rails apps for new web software. And in the keynote he admitted the designers’ vibe-coded work on Basecamp 5 left the architecture “a little like Swiss cheese”, and they went back to manual review.
Problem is, the rest of us need to work now, and the next model might not be perfect. The Rails Foundation’s own Agents on Rails benchmark says it isn’t there yet: the best result on real feature tickets is 53.3%2, and most models score 15–35%. The timeline is unclear. Of course, if the next model removes the need for anything but machine code, this is all moot. But we’re in the aftermath of one tipping point, not past a second, greater one.
Rails’s opinions used to be all about step 2. The keynote put all the certainty on the destination and handed the path to the next model release. That’s the only plan for step 2: “give it freaking 5 minutes.” Robby Russell reflected in his keynote that folks need “somebody willing to say, ‘We’ve learned enough from these experiments. We’re doing it this way now.’”
Jeremy Daer, moderating the fireside chat between Matz & David asked whether words like “slop” and “meat proxies” were diagnoses or coping mechanisms. David said “90% cope” and that “even the slop grenade is not long for this world.” Jeremy pushed back:
“Slop plus the delivery… when it’s being dumped on them”.
That made me reconsider the other elements of that metaphor that make it really sing: the inaccurate trajectory, lobbed and not watched, the implication of a timer and the difference in experience of the thrower and the receiver.
David said “I don’t mind slop grenades at all… I don’t have to catch”. That’s true for him, both in open source (you can refuse a drive-by PR) and at work (he’s in charge).
That’s not what slop grenades end up being for the rest of us though. Most of us can’t ignore PRs from our co-workers or a 3am page from the explosion of a slop-enabled production incident. It’s a thrower’s perspective. We have to catch.
If the models emulate human intelligence with machine determination why wouldn’t having higher level, verifiable, abstractions be useful? That’s why you can spin up a calculator or a Rust duplicate of an existing Rails app. The irresistible force of the agent has something to check its homework on: a bunch of industry standards, a test suite, an existing implementation. Aaron Patterson made this case from a lower level:
“I’ve heard the argument that AI is just our next compiler… [you don’t read its output] because the compiler made a promise to you… your AI has not made this promise. There is no as-if rule for your English.”
Step 2’s hard part is that the model can’t write your spec. The published failure mode in the foundation’s own AI research is hand-rolling. Matz said it: “we know how to define the goal for the agents… we have to formalize them and teach to the following generations.”
Clarity of aim turns a careless lob into a directed pass. I ported readability from JS to Ruby overnight - its test suite was the guard.3
How is David’s Rust-based HEY backend tested? How far along is it? If it’s checked against anything, the best spec is the Rails app it replaces. The six native apps are impressive and I absolutely agree I’d go for a performant API & native app combination when powered by LLMs. But they are all also based on well-established, native, well-maintained, well-documented, platform frameworks like SwiftUI, WinUI, Jetpack Compose, Qt.
The web has one of those too. As Kinsey Durham Grace put it: “If you designed a framework from scratch for agents, you’d land close to Rails.”
Without aim, a grenade just blows holes in whatever it lands on. Not sure waiting 5 minutes for the models is a good solution to having to solve problems now.
Hot Cell was the only feature that made the keynote4 but Mike Dalessio’s talk was absolutely about how AI is affecting open source (and specifically a Rails CVE) and a framework-shaped answer to holy shit the robots are coming to hack your systems.
Joël Quenneville & Rachael Wright-Munn talked about fixing the system and bolting deterministic hooks, or context-injecting generators, onto your agentic tools. Before Rachael’s custom generators carried RubyEvents’ conventions, the AI “would invent keys”. Merging Marco Roth’s Herb into Rails gives us a parsing tool for the view layer that can escalate errors into an agent’s context.
Kinsey also brought numbers from her time on GitHub’s Copilot coding agent team: 84% of developers use AI to write code, but only 29% trust it. “Generation is really, really cheap, and verification is not”, so reviewing harder won’t fix it. Her answer: “Constraints beat instruction”. A rule in AGENTS.md fades as the context fills; a CI check that fails the build applies every time and costs no tokens. It’s also why Rachael’s generators work. With a generator, “you’re making the command that puts [service objects] there cheaper than writing the file by hand. It’ll take the cheap path because agents always do.”
Robby argued for improving the “workshop” of our apps, making the preferred way obvious for humans and agents. Applying our curiosity to the problems we see in our day to day and leaving things better than we found them.
Jeremy asked what’s past Rails: “I want to keep Rails… what about the values of Rails?” The answer was “find your tribe… stick around.” That’s not a plan for Rails. David’s own tribe, and his energy, is clearly Omarchy, his agent-focussed Linux distribution.
People move on. That’s fine. There’s an entire army of people wanting to do, and already doing, the work before the models (maybe) do all software engineering and the framework doesn’t matter.
8.1.4, a bugfix release, came out on day 2 of the conference. There’s a bunch of cool stuff in 8.2. There’s no doubt an editing job to do to make Rails useful through the AI-chaos era that Mike identified in his talk.
There’s an alt-history version of this talk that pivots on the delight of David’s 21-year-old demo “look at all the things I’m not doing” into a vision for how Rails helps the models and the humans compress and accelerate. Then it was the framework, now it’s the framework and the model. David credited only the model.
Kinsey closed with the version I wanted from the keynote: “Convention over configuration was never really about productivity. It was about care. A predictable and clear place to put things is a message to whoever shows up next… We called it a framework, because somebody always comes next.”
No doubt Rails needs to change—some things in, some things out—but it felt to me like a resignation from this version of his world view. If David’s focus has moved on, that’s his call. There was enough can-do, roll-your-sleeves-up attitude in the rest of the conference to take on the uncertain future.
Mike opened with a timeline: prehistory to modern computing, then “you are here” in a band marked “CHAOS!”, and a giant question mark. That question mark is step 2. It won’t look like the old work. But it’s our work, and you don’t need permission to do it.
He praised it in the keynote and called it ‘a short-term consideration’ the next day. ↩︎
Stage 2 gives models 20 feature tickets, written the way a product person would, against 37signals’ Fizzy app, graded by hidden checks. At default settings the best score was 35%. The 53.3% is the same model, GPT-6 Astra, at maximum effort: 2.6 times the cost and almost three times the time. Claude Fable 5.1 spent twice as much at max for the same 32%. ↩︎
Simon Willison ported a standards-compliant HTML parser (JustHTML) from Python to JS in four and a half hours. ↩︎
class_names helper does this cleanly.
…interpolating conditional classes with ternaries or post-statement conditionals:
<div class="p-4 rounded <%= @error ? 'bg-red-50 border-red-500' : '' %> <%= 'opacity-50 cursor-not-allowed' if @disabled %>">
<%= @message %>
</div>
…the class_names helper:
<%= tag.div class: class_names(
"p-4 rounded",
"bg-red-50 border-red-500": @error,
"opacity-50 cursor-not-allowed": @disabled
) do %>
<%= @message %>
<% end %>
String arguments are always applied; trailing keyword-style entries are included when their value is truthy and silently dropped otherwise.
Better still — Rails tag helpers (tag.*, link_to, form builders) already run the class: argument through the process implicitly, so you can drop the wrapper and hand it an array directly. The trailing key: value pairs don’t need their own {} either; Ruby wraps them into a Hash for you:
<%= tag.div class: [
"p-4 rounded",
"bg-red-50 border-red-500": @error,
"opacity-50 cursor-not-allowed": @disabled
] do %>
<%= @message %>
<% end %>
An active nav link:
<%= link_to "Home", root_path,
class: ["nav-link px-3 py-2",
"text-blue-700 font-semibold": current_page?(root_path)] %>
A form field with errors:
<%= f.text_field :email,
class: ["field", "field--error": @user.errors[:email].any?] %>
A flash message:
<% flash.each do |type, message| %>
<%= tag.p message, class: ["flash",
notice: type == "notice",
alert: type == "alert"] %>
<% end %>
An active tab:
<%= link_to "Overview", project_path(@project),
class: ["tab", "tab--active": current_page?(project_path(@project))] %>
Or wrap a repeated pattern in a helper. Helpers often return Strings, which would be a case where you call class_names directly:
def class_names_for_project(project)
class_names("status-badge",
"status-badge--primary": project.active?,
"status-badge--muted": project.archived?)
end
<%= tag.span @project.status, class: class_names_for_project(@project) %>
The unsophisticated approach ends up with extra whitespace in the rendered HTML with ERB tags inside an HTML attribute (which I’m not a fan of visually), plus it’s hard to scan which classes are always present and which are conditional.
The tag helpers call token_list on whatever you pass to class:, which is aliased as class_names. It splits whitespace-separated tokens, deduplicates them, and returns an HTML-safe string. So ["p-4", "p-4 rounded"] collapses to "p-4 rounded" rather than repeating p-4.
You have to call class_names directly when you’re not inside a tag helper — building a string in a helper method, or interpolating into raw HTML. It’s available in all views and helpers in Rails since it’s defined in ActionView::Helpers::TagHelper. You might also see it referred to as token_list, which is the original method name.
If you’ve only got a single conditional class, plain ERB is readable enough:
<div class="p-4 <%= 'font-bold' if @important %>">
Though the array form does avoid the awkward whitespace issue when the condition is false:
<%= tag.div class: ["p-4", "font-bold": @important] do %>
html_safe on the result. This bypasses Rails’s built-in XSS protection entirely: any user input in that string goes straight to the browser unescaped.
The good news is you almost never need html_safe. Rails provides three underappreciated tools that handle escaping for you.
…calling html_safe on strings you’ve built by hand:
def status_badge(label, color)
"<span class=\"badge badge-#{color}\">#{label}</span>".html_safe
end
def formatted_address(user)
[user.street, user.city, user.postcode].compact.join("<br>").html_safe
end
def render_comment(comment)
comment.body_html.html_safe
end
…the right tool for each situation.
When you need to build HTML elements, use tag helpers:
def status_badge(label, color)
tag.span(label, class: "badge badge-#{color}")
end
The tag helper escapes the content and attributes automatically. It returns an HTML-safe string without you having to think about it.
When you need to join fragments that mix safe HTML with potentially unsafe text, use safe_join:
def formatted_address(user)
safe_join([user.street, user.city, user.postcode].compact, tag.br)
end
safe_join escapes any unsafe strings in the array and returns an HTML-safe result. It’s Array#join with protection built in.
When you need to accept user-provided HTML but strip dangerous tags, use sanitize:
def render_comment(comment)
sanitize(comment.body_html)
end
sanitize keeps safe tags like <p>, <strong>, and <em> while stripping <script>, event handlers, and other XSS vectors. You can customise the allowed tags and attributes, but beware of straying past the defaults — they are battle-tested and loosening them is a footgun.
Each of these tools lets Rails manage HTML safety for you. You describe what you want — an element, a joined list, sanitised content — and the framework handles the escaping.
html_safe does the opposite. It tells Rails “trust this string, don’t escape it”. That’s a promise you have to keep, and it’s easy to break when the inputs change or a future developer doesn’t realise user data flows through that path. Ask your friendly security consultant or penetration testing organisation why this is a bad idea.
The mental model is simple. Need an HTML element? tag. Joining fragments? safe_join. Accepting rich text? sanitize. If none of those fit, you probably need a partial or a component, not a string.
There are legitimate uses of html_safe. Some gems, like pagy, return pre-built HTML strings that are safe by construction. Calling html_safe on their output is fine because the gem controls the content.
You might also see html_safe on strings that are genuinely static with no user input, like " ".html_safe. That’s harmless, but you can include the actual Unicode character instead — "\u00A0" gives you a non-breaking space without needing html_safe at all. That is ugly as hell though, so it’s your call!
The key question is always: could user input end up in this string? If the answer is yes, or even maybe, reach for tag, safe_join, or sanitize instead.