Tommi Space

🚧 Work in progress 🏗️

Content of this page is not complete: unfinished notes and articles are tagged with draft tag

tommi.space


latest edit:

These notes are random thoughts rather than a log. My intention was to track changes to tommi.space, but I fail to document everything because it takes time and I am lazy..

As I am not a developer or designer by profession, documenting my decisions for educational purposes is not my priority.

This page follows a reverse chronological order. Sections are marked by date.

Version 2!

I completely rethought tommi.space. I explain what marks this new version in a dedicated post.

The major change marking this new version is philosophical, but I changed a few nice technicalities, too.

Heading font

I love Inter, but using it everywhere is becoming quite boring. I have been thinking about choosing a cool whimsical font to use in headings for a while.

I chose to use Permanent Marker since it wonderfully reflects the work-in-progress mood of the website.

Remove the share section

As with the analytics, I realized that the share section is quite useless, and the page weight and performance vs utility ratio is not worth it. Removed that, too! How liberating it is to just strip away all extra stuff!

Dropping Gemini

I did not log it here, but in late 2022 I set up a Gemini capsule for tommi.space, meaning a modified, minimalist version of this website was made available via the Gemini protocol. I developed a script to build and deploy the capsule, and I configured a Gemini server in YunoHost to publish it.

As time passed by, something in the workflow broke, and I did not have enough time to fix it. This made me realize that geek stuff such as Gemini should be fun experiments rather than growing maintenance burden of an amateur self-hoster like me.

I do not exclude to bring the capsule back to life if I feel like it, but I want to keep things light and joyful. Not thinking about it for a while.

No analytics!

I realized that I do not actually need analytics on this website. I uninstalled umami and I removed any client-side tracking. I did so for multiple reasons:

  • I rarely checked the data
  • Data was not reliable, since visits.tommi.space is now listed in the easylist blocklist. All the people using ad blockers did not appear at all in the stats.
  • Loading the analytics script took the website ~700ms longer to fully load.
  • I should learn to analyze server access logs, and I could use [server-side analytics](https://plausible.io/blog/server-log-analysis ‘Client side vs server side analytics: What’s the gap in data? | Plausible blog’)
  • In the end, do I really care about how many people visit this crazy place? I do not need to see numbers, but to get feedback, create actual, direct, interactions!

Finally, after three years since rewriting this website from scratch, I found Pagefind to be the perfect search solution, both in terms of ease of use and performance.

Self-hosting

By migrating Xplosion Server to a slightly more performant machine, I ended up messing up some configurations, and I also realized that my website publishing workflow was not really independent and stable. Therefore, I decided it was time to self host tommi.space.

Details on !Self-hosting tommi.space

Issue tracking

Up to now, anything concerning website ideas and development was listed quite randomly on the website development page. My intention was to keep everything portable and within The Jam. Nevertheless, tracking both bugs, feature ideas and stuff to do with services dedicated to that is easier, simpler, and much more integrated with the development environment and workflow that git provides.

I am now using GitHub for issue tracking, even though the repository is currently being hosted on giTMI, and mirrored on Codeberg

Hosting

Since the beginning, Netlify has been where tommi.space is hosted. It has to be noted, though, that Netlify is no champion of openness, free software, or sustainable infrastructure, hence not a service whose values I completely share. Nevertheless, it is awesome, since at the same time it both has more than what I need, and it is fairly simple. It hurts to say it, but I love it and I am sticking with it, since it really makes much of the work easier.

All of the relatively big files on the website (such as images and podcast audios) are hosted on Storj, and through a couple of tricks they are seamlessly served through Netlify. Storj too has its red flags, since it is based on the blockchain and I am still quite skeptical concerning all of this stuff. But, again, it wonderfully does the work, at least until Cubbit won’t get around static hosting, as Stefano, its CEO, anticipated to me someday it will.

Analytics

The sole aspect I am interested in is knowing how many people visit my website, specifically which pages.

Being Google Analytics definitely out of consideration, finding a simple, free, light (and hosted) analytics service is not simple.

  • counter.dev is the most clever, the lightest, and among the most beautiful analytics software I have ever seen. Unfortunately, it has some big problems that make its numbers not remotely corresponding to reality, and its developers do not plan to fix them anytime soon.
  • Matomo is the go-to Google Analytics alternative, but, as such, it has many features that I do not need and that make it quite heavy.
  • Plausible is the analytics service I have been using in the last two years, even though it does not feel 100% right, even if it nicely does the work I require. Probably, it is because it costs me a little more than 30€ a year, and I would like to avoid such expense.

Of course, I prefer to self-host analytics, but as of right now Matomo is the only analytics platform packaged for YunoHost (the OS I am using on Xplosion Server). As soon as any light analytics software will get packaged for YunoHost, I will switch to it.

Migrating from GitHub to Codeberg

I love community-driven stuff, and I praise Codeberg values. Furthermore, there is all of that stuff that is not good about GitHub, so I moved.

New repository

I never gave too much attention to the size of the repository of tommi.space, until it clearly huge, with a size of ~1GB. I took advantage of the switch to Eleventy to start a new repository from scratch. The obsolete Jekyll-based website is on GitHub at old.tommi.space

Switching to Eleventy

My switching from Jekyll to Eleventy is one of those things that was not strictly necessary, yet I kept thinking about it every time I coded something, even minimal, on Jekyll. So I switched. It has been very stressful and intense, but I am now thoroughly proud of the fundamental structure of my website, even if it still lacks some features it had with Jekyll.

There are plenty of step-by-step guides to switch from Jekyll to Eleventy. Even though tutorials have been of little use for me, since tommi.space is heavily customized and tailored, I saved (and I am still continuing to save) insightful articles about Eleventy.

Equally, there are a ton of blog posts comparing the two static site generators, but, again, I am just interested in noting my personal reasons.

  • Eleventy now has around three full time development funding working on it. Jekyll is arguably dying. The only consequence I am interested in is support: even after posting the most absurd or tricky question on the Eleventy discussions, I get an answer in less than 40 hours. On the Jekyll forum, I often relied only on the help of Michael Currin, who to my eyes quickly became some sort of divinity (as Peter DeHaan is for help with Eleventy), but I could never get 100% of what I was looking for.
  • I have no intention to start coding as my main activity. Still, it is undeniable that the more coding skills, the better it is on this crazy planet in the 21st century. After such premise, it goes without saying that a SSG built with JavaScript (such as Eleventy) is to be preferred over one that uses Ruby (such as Jekyll).
  • A relevant consequence of the point above is that while with Jekyll I was completely dependent on (and blocked by) plugins and their developers, I now have a little (yet growing) possibility to code some simple features myself, since I am slooooowly learning its basics.
  • I do not care much about build time, but when on Jekyll it surpassed the 120 seconds, it started to become incredibly itchy and time-consuming to do anything. Eleventy crashed that time down to less than 30 seconds. Considering the average of build times, it still is quite a lot, but I have no time to spend in build speed optimization. It is fine like this.
  • It is not a logical not objective argument, but while building Jekyll I continuously got many warnings and frequent errors too, even without changing anything—mainly, I believe the main reason were outdated dependencies. I could not stand it anymore.

Sidenotes

Sidenotes are awesome, and after taking a look at Koos Loijesteijn post about them, I figured it would be great to implement them on here, too.

I decided not to, for now, for three main reasons:

  1. They are impossible to be implemented in Markdown, they need a lot of HTML and I don’t have the skills for making a Jekyll plugin to transform footnotes in sidenotes (but it may be a great idea to create one)
  2. I could easily create an {% render sidenotes.html %} where I could pass as arguments both the note content and the word linked to it, but it wouldn’t satisfy me for two reasons:
    1. In the case of printing, it would be a great mess.
    2. On other readers or Markdown parsers outside of Jekyll I’d have a massive chunk of unrendered ugly text
  3. Considered the reasons above, it’s not worth it. I use footnotes very few times (even though I massively over-use parentheses (as I am doing right now)) and with the lovely arrow[1] automatically created, it’s painless to use them.

Further reading

Minimalizing

!Minimalizing

Algolia

It is not the best solution in terms of speed and dependance, but it is still valid temporarily. Search functionality is very useful, so it is a trade-off I am willing to accept—temporarily).

Following these instructions the setup is quite simple. What is annoying and long to effectively customize is the front-end CSS, which I eventually decided would be simple to write from scratch by myself.

Typography and layout

Even though I love Typography, I am never fully convinced about this website layout and design. My concern is not much about coloring, and typesetting, but about layouting, spacing and positioning. I am trying to understand the core of how layouting works by reading at a tremendously slow pace Richard Rutter’s Web Typography.

I will be noting below my doubts and, if solved, my conclusions.

Questions

The most frequent questions I ask myself are the ones concerning technical aims I need help with, that are logged in the [issues labeled help wanted](https://github.com/xplosionmind/tommi.space/issues 'tommi.space issues').
  • Before headings, should break tags or CSS margin be used for separation between sections?
    • <br> spacing pros
      • effective regardless of the client and the styling
      • full control over exceptions for files
    • CSS spaging pros
      • greater flexibility for changes
      • keeping the content document more clean
To check all of the bugs, feature requests, and ideas, go to tommi.space’s GitHub issues

page-specific to-dos

  1. Lovely arrow test -> ↩︎

Comments

🔎