Tommi Space

tommi.space

These notes have to be considered more a random set of thoughts rather than an actual log. It was my original intention to track here the changes tommi.space undertakes, nevertheless, I fail at documenting everything because it takes time and I am lazy.

Also, being a developer or a designer is definitely not my occupation nor my main hobby, hence investing effort in documenting my decisions is not my priority, as well as to explain passages for educational purposes

Issue tracking

Up to now, anything concerning website ideas and development was listed quite randomly on Website development. 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 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

Notes concerning search implementation.

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 -> ↩︎

Share

Comments