Coding For Fun and For... Learning?

What happened to the "for profit" part?

or: Sometimes, it's interesting to just do things for the sake of doing things, like building a holiday gift shopping tracker.

While I'm writing this in August 2026, I'm already thinking about how I'll blink and it'll be the holiday season once again. Holidays mean gift shopping, and - a worry for me, at least, - not accidentally getting the same thing for a family member as someone else.

This post is not a product pitch. I'm not about to sell you an app that's the solution to all your gift-giving-coordination problems. I don't want to do that. What I want to convey is that this scenario gave me a perfect opportunity to learn and practice some development skills.

Most of my development focus is usually centered around TypeScript or Python, as these languages are (currently) what's most useful in my day-to-day. (Not counting infrastructure and container management of my homelab with Docker and Ansible + some gitops). However, there's a language and framework that - up until this past holiday season (... yeah, 9 months ago) I hadn't really thought much about - was an itch I now felt I needed wanted to scratch.

Ruby on Rails.

Ruby on Rails (RoR, or just Rails) is a Ruby-based web application framework. It follows the Model-View-Controller (MVC) architectural pattern, meaning there's an internal way of describing the application data (model), a rendered representation of the application for a user (view), and the logic that connects the two (controller). Rails is not the only framework that makes use of a design like this necessarily, but I found that I appreciate how easily Rails made it to adopt the pattern versus other web frameworks.

As I mentioned, this is not a product pitch. I should add, it's also not a tutorial. That being said, I'll still mention some commands and actions that I took throughout this project.

The idea was simple - I want to be able to have friends and family sign in to a web app, list if there's anything in particular that they'd like as a gift, if anything, and then anyone else in a shared group with them can see what they might want, and what others already plan to get them. This way, as long as everyone participates, there's no gift duplication. (As I write this, I think this is less of a problem than I've made it out to be, but once I asked myself the question "could I build this", I needed to try).

Getting the boilerplate code generated (with scripts, NOT an LLM, mind you) was quite easy! After installing Ruby and the Rails gem, scaffolding a new project was as simple as: rails new gift-tracker. Rails' great documentation helped me grasp what the many new files in front of me were: https://guides.rubyonrails.org/getting_started.html#directory-structure

Rails also comes with plenty of scripts to get things moving fast:

• adding a database: bin/rails db:create
• running a local copy of the application for development and testing: bin/dev
• adding new data types to the model: bin/rails generate model Gift name:string link:string

In addition to what's built in with Rails, there's a great selection of gems to help add functionality - the one I used for authentication, for example, was Devise. And to avoid an open internet-facing sign-up, I also used DeviseInvitable to send invitations by email to friends and family to enable them to register, rather than asking them to start the process on their own.

Because this was a personal project that I had some time to explore, I also took the opportunity to try out Tailwind CSS for styling the application. I didn't try to go for the most gorgeous UI possible, but it made adding styles to my views pretty easy without really having to write much CSS (a weak point for me).

After developing the application, it needed to live somewhere. The quickest way to get it stood up was, magically, already almost ready. When Rails scaffolded the application, it included config/deploy.yml, which allowed me to specify the server I wanted to deploy the web app to, and the hostname to expect for when I proxied traffic to it. This is the magic of Kamal, a tool to help build the application in Docker and deploy the image + a proxy to the image wherever you want.

I wanted to self-host this, so I spun up a VM in my homelab, pointed Kamal at it, and also installed Cloudflared on the VM to tunnel traffic to a domain my family and friends could visit through to the application.

What I learned:

• Rails' "convention over configuration" approach genuinely sped things up - once a model existed, generators and scaffolding handled a lot of the boring parts that might require more manual work in TS or Python in my experience so far.
• Devise (and DeviseInvitable) handled almost all of the auth boilerplate - sessions, invites, and the like
• Tailwind was handy for getting something that looked decent without slowing down iteration - a nice balance for someone (me) who doesn't love writing CSS
• Kamal supports zero-downtime deploys out of the box, and I could set up a secondary staging environment to test changes before they hit prod
• I want to try more with Rails

tl;dr

For the 2025 holiday season, my gift to myself wasn't a thing. It was giving Ruby on Rails a try, purely for the fun of learning something new. And it turned out to be a very fun framework to use, mostly because, above all else, it just worked.