Forem: Paul (hxii) Glushak

Automating the Boring Stuff

Paul (hxii) Glushak — Thu, 16 May 2024 15:25:01 +0000

This is copy pasted from my blog with added commentary below.

The idea for boku came from my dayjob, where we developed a robust onboarding script that takes care of setting up development environments for new onboardees.

While the onboarding script we use is robust and comfortable, it requires knowledge in Python to be able to add even the simplest of tasks to it. Moreover, each addition requires the binary to be recompiled and redistributed, so the portability and versatility of this tool suffers as a result.

Boku then comes to bridge this gap, yet is not intended to replace much more robust tools in order to keep it's simplicity.

The TL;DR is -

Was bored
Thought it might be useful because I personally need it
Learning experience \o/

The idea to automate things is doubtfully foreign to any of us, as we constantly seek better, more creative, more efficient ways of achieving certain results and completing certain tasks, while, if we're being honest, investing as little resources as possible.

~/d/onboarding master• ❱ pygount . --suffix py -f summary
┏━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━┳━━━━━━┳━━━━━━┳━━━━━━━━━┳━━━━━━┓
┃ Language      ┃ Files ┃     % ┃ Code ┃    % ┃ Comment ┃    % ┃
┡━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━╇━━━━━━╇━━━━━━╇━━━━━━━━━╇━━━━━━┩
│ Python        │    52 │  94.5 │ 3571 │ 54.7 │    1090 │ 16.7 │
│ __empty__     │     1 │   1.8 │    0 │  0.0 │       0 │  0.0 │
│ __duplicate__ │     2 │   3.6 │    0 │  0.0 │       0 │  0.0 │
├───────────────┼───────┼───────┼──────┼──────┼─────────┼──────┤
│ Sum           │    55 │ 100.0 │ 3571 │ 54.7 │    1090 │ 16.7 │
└───────────────┴───────┴───────┴──────┴──────┴─────────┴──────┘

It's easy to throw in overkill solutions (or money) at problems, and while the outcome will most likely be the same, the resources required or wasted (let alone the lack of any newly gained knowledge) will most likely offset the benefits.

These are the thoughts I had in mind while thinking about ways of improving the aforementioned onboarding script.
However, the ultimate decision for the onboarding script was to leave it as is complexity-wise, and improve it in other areas, but take the basic premise of developing a code-less solution for small tasks into a separate tool.

Just as an example, here's how a simple task could look like:

version: 0.0.4
information: |
    Create a Mise config in the folder.
    Author: Paul Glushak (paul@glushak.net)
variables:
    config: |
        [tools]
        python = "latest"

        [env]
        _.python.venv = { path = ".venv", create = true }
tasks:
    create_config:
        run: |
            cat > .mise.toml << EOL
            variables.config
            EOL
    trust:
        run: mise trust

That is how TaskRunner™ was born! Yea, very original, I know. Worry not, now it's called boku.

The intention was, and is to keep the feature set simple, and make the tasks portable, hence the YAML files. This also allows boku to tie in to an existing workflow, or be run as a cronjob.

~/d/boku main• ❱ pygount . --suffix py -f summary
┏━━━━━━━━━━━┳━━━━━━━┳━━━━━━━┳━━━━━━┳━━━━━━┳━━━━━━━━━┳━━━━━┓
┃ Language  ┃ Files ┃     % ┃ Code ┃    % ┃ Comment ┃   % ┃
┡━━━━━━━━━━━╇━━━━━━━╇━━━━━━━╇━━━━━━╇━━━━━━╇━━━━━━━━━╇━━━━━┩
│ Python    │     4 │  80.0 │  473 │ 75.4 │      47 │ 7.5 │
│ __empty__ │     1 │  20.0 │    0 │  0.0 │       0 │ 0.0 │
├───────────┼───────┼───────┼──────┼──────┼─────────┼─────┤
│ Sum       │     5 │ 100.0 │  473 │ 75.4 │      47 │ 7.5 │
└───────────┴───────┴───────┴──────┴──────┴─────────┴─────┘

To conclude, as with other tools and things that I developed for personal use, I often find that a tailor-made brick can be 100% more effective than a generic, mass-produced spaceship (Wonderful analogy, I know!), depending on the situation of course.

Seek to improve, strive for efficiency and don't be afraid to make stuff for yourself and by yourself. Worst case - you're gonna learn something new.

Check out boku on SourceHut.

Notes.cx

Paul (hxii) Glushak — Thu, 29 Jul 2021 09:53:17 +0000

Notes.cx is a simple public note taking app where every note you create (anonymously) lives for 24 hours.

Every time you open the main page, a random ID is being generated for an empty note.

You can compose your note using Markdown syntax, or just paste a bunch of text if you don't want it to look pretty ¯\_(ツ)_/¯.

After you're done writing, just hit Enter or click Create and share your note with the world.

Any note you create (which lives for 24 hours) can only be edited by you.

Check it out at https://notes.cx/

diary.by

Paul (hxii) Glushak — Thu, 22 Jul 2021 12:40:14 +0000

Very excited and happy to introduce my new project - diary.by!

diary.by is a project I've been carving away at for some time now. It's a super simple blog/diary/notes/journal platform that will let you write in peace, without tracking, ads, likes and other digital noise. The focus here is to give you a simple, easy to use and clean slate on the internet to share your thoughts with the world.

You can check it out here: https://diary.by/
Example post: https://diary.by/~paul/minimalism-again

Note: diary.by is currently invite-only. If you'd like to try it out, please send me a DM and I'll be happy to provide you with an invite code.

Text Summarizer Experiment

Paul (hxii) Glushak — Tue, 19 Jan 2021 10:41:04 +0000

Another weekend, another experiment. This time I decided to dawdle around a bit with text processing.

The actual goal was to come up with an automatic tagging system for my personal KMS/KB project (you can read about it here) which led me down a rabbit hole of mostly fooling around with text and code as well as a little bit of research.

The automatic tagging was put on hold, but the concept and base code behind it paved the way for this little project and while this is far from being finished and/or actually usable, I managed to learn quite a bit about the process.

There exist libraries and projects that do a much better job, but using something readymade is not as fun now, is it?

The Process
Demo
Code

How-to: Creating a super simple URL shortening service

Paul (hxii) Glushak — Sat, 10 Oct 2020 13:29:20 +0000

You know how they say the best way to learn something is to teach it?
I personally don't have time to participate in something like 100 days of code or anything similar, but that doesn't mean that I shouldn't do something, you know?

So today I will explain how I made a super simple URL shortening service for myself and hopefully it will help some of you.

The code is available here.

Please note: This is my take on a URL shortener and this whole thing is written as an exercise based on my current level of PHP knowledge, so I may revisit this in the future. This is most likely not the best or most efficient way of doing this. Please keep this in mind while reading this and, of course, I'd love to hear from you if you've got any ideas or suggestions.

Why do I/you need this?

Traditionally, I guess, URL shorteners were and are used to make long URLs short. These are often used in places where there exists a limit on the character count that can be used such as Twitter, SMS, Mastodon, various descriptions et cetera.
They can also be used to create "nice" links (i.e. service.tld/mylink is "nicer" than somewebsiteonline.tld/service/longlinkgalore?query=yesplease, right?) and as a way to make sure certain links don't change (e.g. service.tld/blog will always point to your blog's address even if you move to a different domain).

Prerequisites

I am personally using nginx with a directive that forwards all requests to the index file in case the requested path is not found.

location / {
try_files $uri $uri/ /index.php$is_args$args;
}

There is no need for a database as all entries as stored in a file.
Currently, I am using Insomnia to add, remove and list entries. There is no GUI.

The "database"

Instead of using an SQL database that would've indubitably made this more complex than it should be (not by much, but still) we are going to store all entries in a simple file.

To introduce some security, I went with a PHP file that has the following header:

<?php header("HTTP/1.0 404 Not Found"); die(); ?>

This means, that if the database file is accessed directly it will just return a 404 error.
The entries themselves are stored on an entry per line basis with a single space separator between the key and URL, e.g.:

@home https://0xff.nu

The script

The script needs to have a couple of parts in order to work as we want it to:

Variables and Init - Where we store and create the things.
Database - Reading from and storing to the database file.
Router - Routing the request through the correct method.
Redirection - The main purpose of this thing - redirecting the request.
Management - Creating and deleting entries.

Variables and Init

We are using a handful of variables:

private $filename, $database, $prefix;
private $dbHeader = '<?php header("HTTP/1.0 404 Not Found");die(); ?>'.PHP_EOL;
private $authkey = '79A69C0D4B9DFCD94B1BF72799E334D0CC4D1972';

public function __construct(string $filename, string $prefix)
{
    $this->filename = $filename;
    $this->prefix = $prefix;
    $this->readDatabase();
}

$filename - The database filename we initialize the class with.
$database - This is where the database will be stored after it's parsed.
$prefix - Entry prefix, if specified. I am using @.
$dbHeader - The header that should be prepended to the database file.
$authkey - Hashed key that should be used to authenticate management commands.
The contructor method sets the variables with the values given once the class is instantiated.

Database

private function initializeDatabase()
{
    return file_put_contents($this->filename, $this->dbHeader);
}

private function readDatabase()
{
    $this->database = [];
    if (!file_exists($this->filename)) {
        $this->initializeDatabase();
    }
    $rawDatabase = array_slice(file($this->filename), 1);
    foreach ($rawDatabase as $entry) {
        $entry = explode(' ', $entry);
        $this->database[$entry[0]] = trim($entry[1]);
    }
}

private function updateDatabase()
{
    $fh = fopen($this->filename, 'w');
    fwrite($fh, $this->dbHeader);
    foreach ($this->database as $key => $url) {
        fwrite($fh, "{$key} {$url}" . PHP_EOL);
    }
    fclose($fh);
}

initializeDatabase() creates a new file and appends the header to it.
readDatabase() reads the database (or calls to initialize it), parses the entries and stores them into the $database variable. The first "entry" is sliced off as it's actually the header ($dbHeader).
updateDatabase() updates the database $filename with the values from $database.

Router

private function parseRequest()
{
    $request['request'] = trim($_SERVER['REQUEST_URI'], '/');
    $request['query'] = $_POST;
    if (isset($request['query']['key'])) {
        $request['query']['key'] = $this->prefix.$request['query']['key'];
    }
    return $request;
}

public function matchRequest() {
    $request = $this->parseRequest();
    $command = str_replace('@','',$request['request']).'Entry';
    if (is_callable([$this, $command]) && $this->validate()) {
        call_user_func_array([$this, $command], [$request['query']]);
    } else {
        $this->doRedirect($request['request']);
    }
}

parseRequest() parses the request that was made from both the URI and POST data.
matchRequest() routes the request through the appropriate method, else we're calling the doRedirect() method to try and perform the redirect.

Note the validate() method. We use this to make sure the request is authorized:

private function isAuthenticated()
{
    return isset($_SERVER['PHP_AUTH_PW']) && $this->authkey === $_SERVER['PHP_AUTH_PW'];
}

private function validate()
{
    if (!$this->isAuthenticated()) {
        http_response_code(401);
        die();
    }
    return true;
}

If the auth key does not match, halt execution and return 401 Unauthorized.

Note: I am using a basic auth so it's important to use this together with HTTPS to actually be somewhat secure.
You can, of course, implement better security if you wish.

Redirection

Redirection is very, very simple:

private function doRedirect(string $key)
{
    if ($this->doesEntryExist($key)) {
        header("Location: {$this->database[$key]}", true, 301);
    } else {
        http_response_code(404);
        die();
    }
}

If the requested key exists in the database, we simply append a Location header¹ which redirects to the location we want.
If it doesn't, we return a 404 Not Found.

Management

For management, we have four methods: add, update, remove and list entries:

private function addEntry(array $entry)
{
    $entry['key'] = $entry['key'] ?? $this->generateID();
    $this->database[$entry['key']] = $entry['loc'];
    $this->updateDatabase($this->database);
}

private function updateEntry(array $entry)
{
    if ($this->doesEntryExist($entry['key'])) {
        $this->database[$entry['key']] = $entry['loc'];
        $this->updateDatabase($this->database);
    }
}

private function removeEntry(array $entry)
{
    if ($this->doesEntryExist($entry['key'])) {
        unset($this->database[$entry['key']]);
        $this->updateDatabase($this->database);
    }
}

private function listEntry()
{
    $this->response($this->database);
}

private function generateID(int $length = 3)
{
    $id = str_shuffle(base64_encode(microtime()));
    return $this->prefix.substr($id, 0, $length);
}

These are fairly self-explanatory. Each method does the neccessary change and updates the database.
You can also notice that we can create new entries without specifying a key.

If a key is not specified, it will be created by generateID() which, in essence, creates an ID of a specified $length from a randomized, base64 encoded unix timestamp.
You may notice there's no verification if the generated ID already exists, but this should be easy to add using doesEntryExist().

Conclusion

This was fairly easy but still a fun to write excercise. I am certain some things can be further simplified or written better to begin with, so I will revisit this little project from time to time to make some adjustments.

This functionality will probably be added to Saisho or may be on a separate domain, we'll see.

Location header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location ↩

A case for microblogging

Paul (hxii) Glushak — Sun, 27 Sep 2020 14:55:27 +0000

This entry is just me thinking out loud and trying to make a case for microblogging.

Recently I tooted about potentially adding support for microblogging to, at least, my website if not Saisho in general. But this made me think and consider the options, requirements, and ways of implementing this (potentially) minor functionality.

The basic need and idea are simple - a way to distinguish between long-form articles and posts to short updates, shares, and misc posts, but it turns out that implementing this correctly could prove a little bit more challenging than I initially thought.

There are several problems that must be addressed and questions that must be answered:

Necessity - Do I really need to add this functionality? Why not just mix all the different kinds of posts together? Is this going to make my life easier?
File Structure - If I do implement this, would the microblog entries be in the same /data/ folder? A separate folder? How would the files look like? Metadata?
Visuals - How would I display the microblog entries? Should they be in a separate list? Should I emphasize the distinction?

Necessity

To be frank here, I'm not entirely sure I need microblogging, but I do know that I will sometimes refrain from posting something unless I have enough "material", so microblogging would certainly address this.

I guess it is also important to understand what microblogging is in its essence and to the best of my understanding it exists to express thoughts out loudly, draft things and quickly share resources with the people that are following your blog. A replacement for Twitter, if you will.

Maybe for this reason the micro-entries should be separated from, you know, the "actual content".

File Structure

There are two issues here:

Entries require a front matter header. The whole point of microblogging is for it to be a quick way to share information, so writing metadata doesn't make sense.
All entries are stored in the /data folder. It would make sense to keep all entries in the same folder, but it would also make sense to separate the micro-entries from the rest of the content, in the interest of keeping some sort of organization.

Both of these would most likely necessitate a code change in Saisho, at the very least the separate data folder part.
The header conundrum can be resolved by using an API that will create the files with the appropriate metadata - which will make creating entries even simpler.

There are a few ways to go about this:

Separate data folder but metadata stays - core code change which means everyone gets microblogging. Will probably require API to create micro-entries.
Separate data folder and no metadata - core code changes with an extra side of code changes, as metadata will be taken from filename and fileinfo.
Same data folder and metadata stays - no core changes. Doable by using a "magic" tag and the implementation relies on the template.
Same data folder and no metadata - requires core changes (same as #2), but implementation is the same as above.

Visuals

I do believe it's obvious that micro-entries have to be separate from the rest of the content in one way or another, as having them mixed with the other content will either
A. Create visual clutter.
B. Make articles hard to find with the number of micro-entries or
C. All of the above.

Think of this as a "blog" vs. "professional content" or similar terms.

Since we know a distinction HAS to be made, the question then is what is the best way to do it. Is it a separate page? A list similar to the article list? If so, should it be on the same page? If not, should I only display the latest entry? All entries? N entries?

==This is the part I'm struggling with.== I will be exploring different methods and update this article accordingly.

Let's Discuss

What do you think about microblogging? Do you or would you utilize something like microblogging?

If so, what do you think is the best way to do it correctly?

The Chosen Path

After writing the article above, I continued thinking, testing different things, and working on implementing the microblogging functionality given the constraints and requirements that I have from the microblogging functionality into Saisho.

Source File

I wanted to make sure the source file is humanly readable even when looking at it directly, so I've decided on using a plain TXT file in reversed order (latest entry is always at the top) that follows a very simple format:

{RFC3339 Date}  {Unique ID} {Flags} {Entry text with MarkDown}

A sample entry would look like this:

2020-09-26T21:17:34Z    ed58b9 P Aside from the ID and the flags (still need to figure out if I *really* need those), the format is TWTXT compatible.

As you can see, the format is twtxt compatible (aside from the ID and flags).

Flags are TBD as I've added them thinking I'll find use (for example P for Published, S for Secret, etc.) for them, but I'm not entirely sure yet.

Presentation

I've decided to have an entirely separate page for the microblog to make sure people can actually get to it (the other option is having it below the main article list).

A new 'special' page was made in Saisho to make this happen:

case 'microblog':
    include_once INC_DIR.DS.'microblog.php';
    $mb = new microblog('blog.txt');
    $entries = (isset($requestedPage['query']['id'])) ? $mb->getEntries($requestedPage['query']['id']) : $mb->getEntries('all');
    $content = (object)[
        'title' => 'Microblog',
        'body' => $mb->renderEntries($entries),
    ];
    $page = (object)['type'=>'microblog', 'content'=>$content];
break;

This made me realize that creating 'special' pages in Saisho is less than comfortable, but this will be addressed at a later time.

As you can see, I've made it so that you can link to specific entries in the microblog by using /microblog?id={id-of-entry} or if you navigate to /microblog without an ID, you'll get all the entries.

The microblog is using Slimdown as opposed to Parsedown which is a very simple and quick Markdown parser with a very limited subset of tags.

The output on the microblog page is a simple ID (which gives you the date when you hover above it) and the parsed entry text.

Posting

Currently, adding new entries to the microblog can be done either by adding them directly to the source file (less than ideal since you need both the timestamp and ID) or by using a simple API.

The API currently only supports creating new entries, but I might modify it to support changing and removing entries as well.

Closing Words

This is still a learning experience for me and things may change depending on my requirements from this functionality. That being said, I am trying to keep it (and everything else in Saisho) simple and functional in a way that I will use it.

The format might still change depending on if I can find a use for flags and I still need to revise and refine the API.

The code will be pushed to both Sourcehut and GitHub once I verify that everything is working as it should.

Got any ideas? Want to discuss this? I'd love to hear what you think.

Image Optimization for The Web

Paul (hxii) Glushak — Wed, 09 Sep 2020 08:37:15 +0000

In my previous rant about web bloat I briefly spoke about image sizes and incorrect image usage and what you can do to either reduce it or make your visitors' life easier.
A specific toot prompted me to continue and expand about this with the hopes that this information will help some of you.

TL;DR

Images, like anything else, are to be use to answer a need or solve a problem¹ (like demonstrating something in a visual manner).

If you don't absolutely need images - don't use them. If you have to use images, make sure they are optimized.

Image Formats

Many things have been said about image formats and I will most likely have nothing new to contribute, so instead I'll direct you to some useful reading material:

Image Size

Before I delve into fancy (and helpful) tricks that you can do to make sure your page load speeds are not inhibited by images, it is important to deal with the root of the problem - image size.

As I mentioned in my previous rant (linked above), I often see websites usings images of disproportional sizes (both image dimension and filesize) to their intended purpose where people would, for example, use a large (1728x1152) profile photo and resize it via CSS (to 30%, effectively 496x331 on a 1080P display):

I'm not going to rant (again) why you really (really) shouldn't do this, so we'll get straight to it.

Optimize. Optimize your images. Deal with the dimensions first - if you know you're only going to use 30% of your image, resize it beforehand!
Using smaller dimensions will also result in smaller filesizes.

You think larger screens deserve larger images (not of your fucking face, please!)? Save multiple sizes and use srcset.

You made your images smaller? Thank you! You want to go the extra mile? Use optimization tools, either online or offile. For example:

Online Tools

Offline Tools

Know any other good tools? LMK.

Lazy Loading

Unless images are part of the layout, you should always be using lazy loading.

Lazy loading will make the page load faster, as images that are offscreen will not be loaded until they are scrolled into view.

All you have to do is add loading="lazy" as an attribute to your img tags, e.g.:

<img src="path-to-img.jpg" alt="Image description" loading="lazy">

You can read more on CSS-Tricks about Native Lazy Loading and The Complete Guide to Lazy Loading Images.

Going the extra step

Your images have been smallified and are lazy, but you want to do a bit more, huh?
Another thing you can do is make sure images are only loading once a user triggers them.

The JS route

This is a technique I employ here, on my website, and it consists of setting a placeholder as the image source and the actual image under a data-src attribute, creating a listener and switching the sources once the user clicks on the image.

Image example:

<img src="/load.png" data-src="https://0xff.nu/i/Tubby-ae0ddc24569cabab.png" alt="Holy fucking unreadable font, Batman!" loading="lazy">

The JS code:

  <script type="text/javascript" defer>
  const images = document.querySelectorAll("img[data-src]");
  images.forEach(function(image) {
      image.addEventListener('click', e => {
          e.target.src = e.target.dataset.src;
          image.removeEventListener('click', e);
      });
  });

The CSS route

If you don't want to use JavaScript (I wouldn't blame you), you can achieve a similar effect using HTML and CSS. You can see a little demo I wrote on Codepen.

The gist is to place the image offscreen or hide it using a CSS rule and use a checkbox element to switch the styling once it's checked.

For example, the HTML:

<div class="fig">
  <input type="checkbox" id="loadimage" name="loadimage">
  <label for="loadimage">Load Image</label>
  <img src="https://images.unsplash.com/photo-1568431477192-52bb13a55088" loading="lazy" alt="A cute hedgehog">
</div>

And the CSS:

.fig {
  display: inline
}

.fig label {
  color: blue;
  cursor: pointer;
  text-decoration: underline;
}

.fig input {
  display: none
}

.fig img {
  position: absolute;
  left: -9999px;
  display: none;
}

.fig input:checked ~ img {
  position: relative;
  left: 0;
  display: block;
}

This might be a bit less straightforward and more cumbersome solution, but it works.

In conclusion

You don't have to do this, and you might argue how this is kind of fucking annoying in terms of UX, especially if you are using a lot of images, and you'd be right and this is exactly where you need to excercise common sense.

Closing words

Images are only part of the web bloat, but they could be one of the easier things to fix. Everything depends on you and how much effort and thought you're willing to put into this.

The important thing is that we acknowledge the problem and take steps towards fixing it, rather than contributing to it.

Let's make the fucking
web nice again, shall we?

Part of my, I guess, way of minimalism, is that when writing code, if something doesn't solve a problem, answer a need or makes someone's life easier it's most likely not required. This is true for many things, images included. I only reserve images for things I cannot show using text. ↩

Pursuing Speed, Pt. 3

Paul (hxii) Glushak — Sun, 16 Aug 2020 12:42:08 +0000

This entry (and collection of links) is a continuation of Pursuing Speed, Pt. 2 which you can read for context.

You are more than welcome to share the link to this with your friends and colleagues.
If you'd like to contribute relevant points of interesting links or resources, ~~please contact me using the form at the bottom of the page.~~ Since this is dev.to, please leave a comment and I'll update the post with the links.

At this point, you might be going "This dude can only rant! Provide some alternatives, then!" and, in a sense, you'd have a point, since all I did so far is rant and only briefly talk (or rather mention) the "correct" way to go about things.

So it's time to remedy this. In this post, I will try to provide tips and rough guidelines as well as links to further reading which will help you in making your website faster and more accessible.

As I've said before, speed, lightness, mindfullness and minimalism do not neccessarily mean that your website must or will look as minimal (and some would say barren) as mine, not at all! You can have colors, images and whatever fucking flashy, hip things you want, but you MUST be mindful with everything that you add. Dont use jQuery just to do a fucking POST call and don't use Bootstrap just because you're fucking lazy.

The least you can do

Base

In order for your website to be quick, it needs to have a solid, lightweight base. To ensure this, my solution was to create my own website engine that will fit my needs. You, of course, don't have to do this, but you do have to take your base into account as it's probably the most important aspect.

WordPress is bloated¹. You need a plugin for even the most basic things which make the platform even heavier. This is not to say that WordPress is bad per se, but it is more often than not an overkill solution just to handle your blog or journal.

If you can afford it, use a static site builder like 11ty or literally anything from StaticGen. If you need a CMS, use lighter solutions like Bludit, Grav or Automad.

Accessibility

Making your website more accessible to different kinds of people probably was not in your list of considerations, but you can now help change this. There are tons of small things you can do which will ensure a lot more people can read your website comfortably.

Animations - Want to use animations? Great! But please note not everybody likes (or can stomach) this fucking trash:

Animations, at worst, need to compliment your content and enhance the user experience, and at best not to be used at all.
Still want to use them (in moderation, of course)? Sure, BUT also use the prefers-reduced-motion ² media query. This way, those who do not wan't to see animations will not be forced to do so.

Colors - Use tools like this to make sure the colors you are using are contrasty enough.
While some say dark mode (or night mode) is not important, it is becoming way more requested and needed. Besides, it is now easier than ever to implement using the prefers-color-scheme³ media query, so why not add it?

Fonts - Avoid webfonts if you can. The system stack is usable enough for most people. If you are using webfonts, don't use unreadable shit like this:

Relevant reading:

Frameworks

Want to use a framework? Don't. Absolutely have to use CSS & JS frameworks? Use them wisely.
How does, for example, loading 500-fucking-kilobytes for 5 social icons makes any sense?

Write your own CSS according to your/your website's needs. Only add classes you're going to use. Optimize.

If you're only using jQuery (31kb) to do ONE thing, I'm sure as hell you can manage to do it using vanilla JS. Need a small framework to make things easier? Check out Cash or UmbrellaJS.

Images

Images are there to compliment the rest of your content. Unless I'm looking at your portfolio of visual arts, don't make me download a megabyte photo of your mug.

Optimize - there's no fucking reason for you to force me to load unnecessary data, for example the illustration here provides no additional value yet weighs 26% of the total page size.
FFS the same image in WEBP is 132kB, which is a 31.6% reduction in size and it only took me 5 fucking seconds to do this.

Resize - The profile image here for example is 1728x1152 pixels yet you're limiting it to 30% in CSS, thus making your visitors download more data than is actually required. WHY? 5 fucking seconds to resize it to 600x400 and optimize and it's a miniscule 17.9 kB instead of 95.1kB, and all it took is some caring.

Lazy loading - Utilize lazy-loading on all the images that you use. It costs you nothing, yet helps a lot.

What else can I do?

This all depends on how much you care. If you care about your website, and you actually put some time in crafting it rather than throwing a bunch of crap together - it will look and perform great.
Make sure to check out client-side caching (if your HTML won't change, you could try caching it as well), preload/prefetch⁴ resources, minification, pre-compressing your resources, read what others have done, and try to stay on top of whats new in web technologies.

The main point I'm trying to get across is this - Experiment to your heart's content, but please give a shit when it comes to a publicly available website, your visitors are not your test subjects. They would rather read what you have to say than bask at the unholy abomination that is your fancy fucking React APP.

Suteba - Simple Request Bin in PHP

Paul (hxii) Glushak — Mon, 27 Jul 2020 14:49:24 +0000

My day job requires me to perform troubleshooting on customer issues, some of which may include trying to understand what might be wrong in an API request payload.

While I could have used a service like requestbin.net, it wouldn't be much of a learning experience, would it?

The solution, then, was to make my own little tool that I could use to help myself investigate these issues, which I have also decided to share with you guys, in case you might find it useful.

I present Suteba.

Simple and light. No trackers. No bullshit.
You own all the data.
Multiple bins/buckets/dumps/whatever.
Listing feature of requests per bin.

Note: Features are sparse to make Suteba simple and light. You're more than welcome to suggest additions, but please keep the simplicity in mind.

Available on
SourceHut
GitHub

Pursuing Speed

Paul (hxii) Glushak — Mon, 20 Jul 2020 16:26:02 +0000

Originally posted on my website which is also a demo.

Continuing my rambling about pursuing minimalism, I'd like to also say a few words about speed having "finished" rewriting my own website engine, once again.

Minimalism and speed (at least when it comes to the web) became a sort of obsession of mine, and I always (try to) stay up to date about any new developments in web development, optimization, caching and other ways of improving speed.

Sure, WordPress can be made fast-er (leaving ironic snake oil aside), but once your base is bloated¹ you will never stop optimizing the behemoth by either removing built-in functionality², installing more plugins e.g. cache, finding clean themes or a combination of the above.

Why, then, not start from a clean base? That is exactly why more and more people nowadays are turning to WordPress alternatives such as Bludit, Ghost, Statamic and others as well as static website builders such as 11ty, Hugo and Gatsby in which it is easier to control what is being loaded and served.

You can of course take it one step further, if you're really inclined towards speed and controlling your own data and delivery. More on this later.

State of the web

The thing is, there is, in my opinion a general disregard towards website sizes and loading speeds: huge fucking CSS frameworks, unoptimized images, unnecessary JS libraries and the list goes on.

I recently found instant.page³ and was immediately interested in the type of websites that might be using it.

Here we have someone's resume that is just one page, but it loads 7 JS files, 1.7kb of CSS and 30kb of fonts. All for one page, to a total of 100kb. At least the damn SVGs are inline instead of loading fucking FontAwesome.

Or this placeholder for someone's blog. How bad is it, you ask? 288kb transferred with no meaningful information presented.

Things are bad, but they don't have to be, as soon as people start caring without just throwing a bunch of shit together and calling it a website.

What did I do?

Preface: What I did was, in a sense, take things to the extreme. I do not think or am saying this level of minimalism is good for everyone, but you can take inspiration and ideas from what I did and implement them in your platform of choice.

The base - Instead of using a ready and working platform I decided to write my own. This allows me to control everything without relying on third parties when it comes to features. CSS was written by hand and only the necessary blocks are present. This may not be for everyone, as for better or worse, making it work is up to you (so is security).
The bloat - There is none. I am using nothing and loading nothing besides the necessities and the page content. No CSS frameworks, no JS libraries (sans instant.page³). Nothing.
The speed - A couple of speed optimizations were done. Some of them may be placebo.
- nginx serves everything with Brotli compression enabled.
- Pages are processed with PHP and the output buffer response is cached as HTML for 3600 seconds.
- Pages are cached in browser using: header('cache-control:public, max-age='.CACHE_TIME.', immutable'); Memcached was also considered.
- Last Modified header is also sent: header('Last-Modified:' . gmdate('D, d M Y H:i:s ', @filemtime($filePath)) . 'GMT');
- Links are prefetched once hovered using instant.page.
- Images are optimized, dithered and stored locally.

All these allow pages on Saisho⁴ to be loaded almost instantaneously, something I am really proud of.

What can you do?

Start caring.

What you do from there is up to you - optimize WordPress to no end, use static website generators, write your custom engine, write static HTML websites or whatever else works for you.

But care about what you're doing and take into account the people who will be visiting your website and their time.

*[SVG]: Scalable Vector Graphics

*[CSS]: Cascading Style Sheets

*[HTML]: HyperText Markup Language

Rightfully so as WordPress is a platform, not a tailor-made solution, but more often than not it's overkill for the average folk. ↩
Functionality here is debatable. jQuery for example is loaded all the time. ↩
instant.page: https://github.com/instantpage/instant.page ↩
Saisho is my semi-static website engine which you are seeing now. ↩

Saishō — Very simple semi-static site engine

Paul (hxii) Glushak — Sun, 17 May 2020 07:57:28 +0000

After I made micro (a minimalist theme for Bludit) and having recently acquired a bunch of spare time thanks to getting fired, I decided to challenge myself to create something I can actually use and learn something in the process. I decided this is something I can share with you as well.

最小 (Saishō) is a very simple semi-static site engine built for speed and simplicity in PHP. It reads all MD files in a folder, parses them, and serves the cached variant.
It was made for those of you that require no bells nor whistles, but something that will allow you (and your visitors) to focus on your content.

Feedback is more than welcome. This is a learning experience. Do keep in mind that the entire point of Saishō is to be quick and simple.

Demo
Guide
Sourcehut
GitHub