Did you know Google essentially mandates that recipe sites follow a specific format or else they will not feature your recipe in their search engine?
I went down a rabbit hole of food recipe madness after posting my first recipe the other day, and I thought it would be interesting to share the craziness that is recipe SEO.
Normally, a recipe post would start with a 1500-word explanation of a recipe and its origin. I don't believe in wasting your time for SEO purposes, so here's the recipe. If you want the why, read on afterwards.
I've been a blogger for most of my life - but now I really want to start making my personal site my own.
18 months ago, I wrote a blog post about my process of documenting my home server's containerized applications.
The very next day, OpenAI announced ChatGPT. I immediately started playing with the new shiny technology that could generate text . My well-intentioned plan to manually document each application according to a formatted template seemed less exciting. Therefore, my plan to have perfect documentation slowed. I focused more on doing more fun things with my server - adding family photo viewing capabilities to my Plex, improving my local DNS situation, and moving some more items from my HDD array to a new SSD.
Documentation for any type of technology project is crucial, especially if there are multiple people working on a project. Even if there's only one person, the human mind doesn't have perfect recall.
My home server started as a simple experimental playground for learning Unix-like operating systems, managing applications, and best-practices for file management. Over the past two years, the project ballooned into a media management server, web server, download client, chat host, cloud server, Git and development server with CI/CD integration all in one.
Each project by itself was manageable by itself, but as someone who is constantly learning and implementing new things, each project tended to build on the previous one. Then, when something broke due to an update or network blip (or more likely, an initial mis-configuration), I would have to go back and attempt to remember what I had done last time. This was annoying but not too big of a deal - it was just my personal project, and the time it would take to document each application wouldn't be worth the time it takes to troubleshoot my apps.
Social media has radically changed the world - I don't think there's a person on this planet that would disagree with that.
Social media is also in a bit of an upheaval phase right now. Twitter has been bought out by an insane billionaire intent on changing the company to a profitable "free-speech" haven, while Facebook is dumping billions of dollars into moonshot "metaverse" projects to maintain their relevance as their core product becomes less relevant.
Social media giants typically have incentives that don't exactly line up with what the user wants to see in social media.
It’s been a while since I have written a blog post about my home server. I’ve been working away on my personal project for a while now, adding more features and more integrations - cool ways to make data do cool things.
I recently had a power outage at my apartment. I keep my server on an uninterruptible power supply to ensure that I don’t lose any data. I also keep my modem and router on the UPS but typically when the apartment loses power, the internet goes down as well. This means my server isn’t accessible - and the external services I’ve configured to depend on it may have a service interruption.
I could use a cloud service like Uptime Robot to check if my services are currently functional and up - it would automatically check if my service is accessible from the view of a third party. These cloud-hosted products cost money and are against my ethos of self-hosting everything I can.
In my last post, I discussed how I was using Docker to deploy web apps on my home server. In the past month since then, I've continued to tinker with my process, and I've learned a little bit more about making it a little easier for myself.
In my last post, I discussed why I decided to move my server from TrueNAS to Ubuntu. Perhaps the largest software-based reason was the ability to use Docker to manage the software on my server. This post is a hybrid between a narrative telling how I got my server working and a guide to do it yourself. If you'd like any help with any of the stuff I list in this guide, feel free to reach out! I'd be glad to help.
In my last blog post (approximately 4 months ago), I talked about the build process and the software installation of TrueNAS, an open-source Network Attached Storage (NAS) software based on FreeBSD. Since then, I have switched away from TrueNAS to Ubuntu Server. I genuinely liked a whole lot of TrueNAS, but there were several reasons that I switched to Ubuntu: