Things I Learned With a Supposedly Simple Project

Hey there!

To anyone Reading this blog, you may or may not know that I recently launched a personal project called What’s the Next Holiday? with the simple and straightforward goal of answering that question in a humorous way.

It’s an extremely simple one-page site with very few interactions, heavily inspired by Should I Deploy Today and Devo Deployar. You’d think that someone with some development experience, like me, wouldn’t have any trouble creating something like this. That assumption is partially correct — the development of the site’s first version (which went through several iterations before reaching its current state) probably took just a few hours at most.

However, since every project is an opportunity to learn — and because, for this specific project, my efforts went beyond the scope of development — I’d like to share a few things I learned while working on something many might consider trivial.

SSL Certificates Are Complicated

As I’ve mentioned before, this project is hosted on Magalu Cloud, running on a VM there. I admit I don’t have much experience with this type of setup and got a lot of help with the initial configuration from my friend André Balieiro a few months ago.

When setting it up, we automated the renewal of the SSL certificate for the domain. Imagine my surprise when I launched the site and found out the certificate had expired!

I spent a day or two trying to fix the automation but ended up renewing the certificate manually. SSL certificates are serious business — browsers strongly discourage users from visiting sites without them. To launch the project, functionality was my priority. In the future, I definitely want to ensure the automation works to avoid the hassle.

The Importance of the Difference Between vh and dvh

This was probably my favorite lesson from this project because it’s a front-end issue I’d never noticed before. If you look at the site’s design, you’ll see a footer at the bottom of the page with a link to the GitHub repository.

That footer has been there since the site’s early versions. However, it was hidden below a scroll on mobile devices. This didn’t happen on desktop or even in the DevTools preview. Why?

I’d used 100vh as the height for the main container. In theory, that’s correct—I wanted to occupy the entire available screen space. So why was there a scroll on mobile? The problem is that the vh measurement on mobile devices includes space taken up by the device and browser UI. This makes 100vh slightly larger than the visible screen space.

How to fix this without breaking the desktop experience, which worked perfectly?

This issue was so common that new CSS units — lvh, svh, and dvh—were added to the web standards to address it. Without diving into too many details, replacing 100vh with 100dvh solved the problem and ensured a consistent experience across all screen sizes.

Sometimes, Less Is More

Since this site is about identifying the next holiday, it makes sense that answering that question is a key focus. However, it’s more complicated than it seems because national holidays don’t always fall on the same date (e.g., Carnival or Good Friday).

The most accurate solution would have been to use the Brasil API, which provides the correct holiday dates for the next 12 months. However, using an external API comes with considerations: validating the information, having a backup plan in case of unavailability, and so on. So, I opted to ask an LLM to generate a JSON file in the format I needed, covering holidays through December 2025. Another notable omission in the code is the lack of automated tests.

These choices have clear downsides. Code without tests is harder to maintain. A JSON file expiring in 2025 essentially puts an expiration date on the site itself. However, these decisions allowed me to move quickly and focus on what mattered most: using my limited time to create the first version and show it to the world.

Making these choices consciously wasn’t easy for someone like me, who cares about code quality. But I’m happy I made them because, in hindsight, they were the only set of decisions that allowed the site to be launched.

Workflows in GitHub Actions

I’d never created a CI pipeline from scratch before. For this project, even after the initial launch, several adjustments were still needed, making a CI pipeline essential. Since I hosted the repository on GitHub, I decided to use GitHub Actions for this.

With the help of ChatGPT and a lot of patience (it took over 20 failed jobs before succeeding), I created a very basic pipeline to update the VM’s code whenever the main branch is updated. Despite the difficulty, this step was a simple yet crucial starting point to enable code updates after going live in production.

Conclusion

Since I don’t have much expertise in the DevOps world, getting hands-on experience with ensuring the delivery of quality code was eye-opening. I was also happy to unexpectedly learn more about things I already do every day in slightly different ways.

What about you, dear reader? What have you learned from simple projects?