Many people these days have house plants. There are many philosophical reasons to engage in the nurturing of plants, and if you don’t have access to a garden, whatever can be potted and kept in a window is all you can really manage. Unless you set up a grow room. If you have a spare bedroom, I highly recommend setting up a grow room. For a brief few months one winter I had a spare bedroom with its own separate heating controls, and set up shelving with grow lights and a humidifier, and even if it didn’t have a million plants growing in it, the warm humid air in the cold, dry winter was enough to make it one of the most attractive places in the house. The grow lights only added to the appeal during the dark season. Perhaps the drawback of having some seventy plants was that they required regular maintenance. Watering, of course, and feeding. But something that had to be done at least every other year, twice a year often being best, was managing the overgrowth. Trimming. Repotting. Et cetera.
Hugo
I’ve used Hugo for several years now to generate this site from Markdown. I’ve also tried in many ways to bend it to my desires, forcing it to do things it wasn’t designed to. It now generates content for me far outside of its spec. In fact, I have it doing things that, per the documentation, simply should not work at all. I’m just waiting for an email from someone saying “hey this page 404s,” even though it works on my machine!
Lately I’ve been working on a redesign. In fact, I intend to publish this article along with the current progress, so if you’re reading these words, you’re looking at the redesign. There are many decisions I have not yet made about where exactly things like the publication date of a given entry goes, or how to incorporate tags (or even how to distinguish them from the internal taxonomical category that Hugo uses in addition to tags). I’m liking some of the changes, and fussing with the details though. But part of this redesign was inspired by a need to incorporate broader varieties of content. This is where Hugo is starting to fail me, because as a web developer, I am struggling to limit myself to the means by which Hugo wants to serve content. I’m starting to think I need a new means of serving my works up to the public.
Trimming the roots
Outgrowth demands a couple of steps. One is trimming the foliage, and another is trimming the roots. This latter steps is nerve wracking because it feels like cutting out the arteries of a living body. How many can really be removed before the musculature collapses from deprivation? A plant is, naturally, quite resilient, and often times you will find recommendations to cut about 30% of the roots off. How does the metaphor apply here, however? Hugo is part of my architecture, and it demands the choice of Markdown be made for my architecture, and it demands that my serving infrastructure be static. For price concerns, I don’t really want to move away from static hosting, at least not too far, but then this means I am creating my own SSG? It makes me feel trapped in the same ecosystem as Hugo, just learning a new tool. I’m not using my knowledge as a web developer as a tool to solve this problem, rather I’m fighting against my knowledge as a web developer so that this tool can behave in the way that it was designed. SSG is still a potential element of my strategy, but I fear I will inevitably outgrow it again, and so any third-party tool is, from my perspective, out of the picture. Why learn something so specific when I know I’ll have to throw it away for something less so?
Still, while my hosting costs are quite low right now, estimates suggest they will double if I move away from static hosting. And once I’m off static hosting, the costs can balloon if I should suffer a slashdotting (or a hackernewsing or whatever is the modern means by which text content risks runaway traffic). The tradeoffs weigh heavily upon this weak mind of mine.
Trimming the foliage
Plants also need a haircut every now and then. Trimming off excess foliage, especially that which gets in the way of its own stems and branches, facilitates further healthy growth. I have a dense canopy of content on the web. Not all of it is even on the same domain. Some of it doesn’t belong on the web at all. It’s just rotting there. Maybe it’s time to trim it back. It may help make room for content that I’ve been wanting to get up here. Not having to put my content in the shape of a given tool permits more rapid iteration. It’s far easier to throw an html doc in a folder, or to even just allow directory viewing for a set of images or audio files, than to deliberate content archetypes and archetype-level styling before I can even consider publication. Branches can get in the way of buds.
But raw HTML is cumbersome to manage. Reduplication of efforts by including the same header content, included CSS files, titles, footers and so on across an entire segment of the site, along with the challenge of automating mass updates to it, is something HTML wasn’t built for. Inevitably, I will need to consider server side includes and SSG if I’m not using a static-site generating CMS.
Repotting: preventing tech debt
The potted plant metaphor wasn’t working. Time to switch to a garden-based analogy for my problems with my website. The three sisters theory of gardening has beans for fixing nitrogen into the soil. It has corn (or other tall, stalky plant) for providing structure for the creepy bean vines to climb. It has a squash, or other low, leafy plant, to shade the soil and prevent weeds from growing. But what if you’re just tired of squash. What if you want to eat some tomatoes. What if you want to grow some herbs. These don’t fit into this architecture. It can be done! But the design of your solution is a function of the parameters. Tech debt arises from a solution built without a full picture of the problem. There’s no issue growing all these plants together, but they don’t work together in the same way as just the three do. Different setup will be necessary. Different maintenance labor will be required. Designing for these expectations will result in a different solution than beginning with the three sisters and adding new siblings to the family.
That’s where I am. I’m trying to predict what my website needs will be for the remaining four hundred decades of my life (pessimistically), so I can design a solution for them in the present day. That may be impossible. So may be the act of avoiding tech debt. Needing to know the entire problem to build an appropriate solution itself may be impossible. Perhaps my website is doomed to be an interleaving of a bunch of tools and strategies. Maybe I’ll just have to stick with Hugo and do things the hard and hacky way. I’ll let you know in a few years.