<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://www.juanvasquez.dev/</id><title>JuanVqz's Blog</title><subtitle>Personal blog by Juan Vásquez (@JuanVqz) — a software developer sharing lessons learned, technical insights, and reflections on the craft of building software.</subtitle> <updated>2026-06-25T12:35:34-06:00</updated> <author> <name>Juan Vásquez</name> <uri>https://www.juanvasquez.dev/</uri> </author><link rel="self" type="application/atom+xml" href="https://www.juanvasquez.dev/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://www.juanvasquez.dev/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Juan Vásquez </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>From Vite to Propshaft + esbuild: Simplifying a Rails Asset Pipeline</title><link href="https://www.juanvasquez.dev/blog/from-vite-to-propshaft-esbuild-rails-asset-pipeline/" rel="alternate" type="text/html" title="From Vite to Propshaft + esbuild: Simplifying a Rails Asset Pipeline" /><published>2026-05-26T09:00:00-06:00</published> <updated>2026-05-25T09:00:00-06:00</updated> <id>https://www.juanvasquez.dev/blog/from-vite-to-propshaft-esbuild-rails-asset-pipeline/</id> <content type="text/html" src="https://www.juanvasquez.dev/blog/from-vite-to-propshaft-esbuild-rails-asset-pipeline/" /> <author> <name>Juan Vásquez</name> </author> <category term="development" /> <summary>The Problem My Rails app was running Vite. It worked — HMR in development, fingerprinted assets in production, Tailwind through PostCSS. But Vite is a JavaScript tool that happens to serve a Rails app. The vite_rails gem, vite.config.ts, config/vite.json, a separate dev server on port 3036 — all to do what Rails can do natively. I wanted to simplify toward a zero-Node future, where the app is...</summary> </entry> <entry><title>Building System Admin Impersonation for a Multi-Tenant Rails App</title><link href="https://www.juanvasquez.dev/blog/system-admin-impersonation-multi-tenant-rails/" rel="alternate" type="text/html" title="Building System Admin Impersonation for a Multi-Tenant Rails App" /><published>2026-05-19T09:00:00-06:00</published> <updated>2026-05-19T09:00:00-06:00</updated> <id>https://www.juanvasquez.dev/blog/system-admin-impersonation-multi-tenant-rails/</id> <content type="text/html" src="https://www.juanvasquez.dev/blog/system-admin-impersonation-multi-tenant-rails/" /> <author> <name>Juan Vásquez</name> </author> <category term="development" /> <summary>The Problem I run a clinical assistance system where each hospital gets its own subdomain, one.doctors.com, two.doctors.com, and so on. Each hospital has its own doctors, patients, and data. The subdomains are enforced in routes, and sessions are scoped per hospital. This works great for hospital staff. But as the platform owner, I needed a way to jump into any hospital’s admin panel for supp...</summary> </entry> <entry><title>Simplifying My AI Dev Setup: What Worked and What I Cut</title><link href="https://www.juanvasquez.dev/blog/simplifying-my-ai-dev-setup/" rel="alternate" type="text/html" title="Simplifying My AI Dev Setup: What Worked and What I Cut" /><published>2026-05-12T09:00:00-06:00</published> <updated>2026-05-12T09:00:00-06:00</updated> <id>https://www.juanvasquez.dev/blog/simplifying-my-ai-dev-setup/</id> <content type="text/html" src="https://www.juanvasquez.dev/blog/simplifying-my-ai-dev-setup/" /> <author> <name>Juan Vásquez</name> </author> <category term="development" /> <summary>A few weeks ago I looked at my dotfiles AI configuration and realized I’d over-engineered it. What started as a clean centralization effort had grown into a web of submodules, global MCP servers, and multi-platform symlinks that I barely used. I’m a Rails developer. My primary AI coding tool is Claude Code, with OpenCode as a secondary option. I’d built a system in my dotfiles to manage AI age...</summary> </entry> <entry><title>From HAML to ERB: Going Back to Rails-Native Templates</title><link href="https://www.juanvasquez.dev/blog/from-haml-to-erb-going-back-to-rails-native-templates/" rel="alternate" type="text/html" title="From HAML to ERB: Going Back to Rails-Native Templates" /><published>2026-05-05T09:00:00-06:00</published> <updated>2026-05-05T09:00:00-06:00</updated> <id>https://www.juanvasquez.dev/blog/from-haml-to-erb-going-back-to-rails-native-templates/</id> <content type="text/html" src="https://www.juanvasquez.dev/blog/from-haml-to-erb-going-back-to-rails-native-templates/" /> <author> <name>Juan Vásquez</name> </author> <category term="development" /> <summary>Why HAML in the First Place When I started building the clinical assistance app, HAML felt like a breath of fresh air. No closing tags. No angle brackets everywhere. Just clean, indentation-based markup: %nav.navbar .navbar-brand = link_to root_path, class: "navbar-item" do %img{ src: logo_path } .navbar-menu .navbar-end = render "shared/user_menu" It was elegant. Yo...</summary> </entry> <entry><title>From Sprockets to Vite: Evolving a Rails Asset Pipeline</title><link href="https://www.juanvasquez.dev/blog/from-sprockets-to-vite-rails-asset-pipeline/" rel="alternate" type="text/html" title="From Sprockets to Vite: Evolving a Rails Asset Pipeline" /><published>2026-04-28T09:00:00-06:00</published> <updated>2026-04-28T09:00:00-06:00</updated> <id>https://www.juanvasquez.dev/blog/from-sprockets-to-vite-rails-asset-pipeline/</id> <content type="text/html" src="https://www.juanvasquez.dev/blog/from-sprockets-to-vite-rails-asset-pipeline/" /> <author> <name>Juan Vásquez</name> </author> <category term="development" /> <summary>The Original Setup When I started this Rails app back in 2018, Sprockets was the only game in town. It bundled your JavaScript, compiled your CSS, fingerprinted assets for cache busting — and you never thought about it. The directory structure was classic Rails: app/assets/ ├── config/manifest.js ├── javascripts/ │ ├── application.js │ ├── patients.js │ ├── hospitalizations.js │ └── ...</summary> </entry> </feed>
