Forem: Pascal Thormeier

How to use Timberborn 🦫 (yes, the beaver city-building game) as a database 💾

Pascal Thormeier — Sat, 28 Mar 2026 19:39:32 +0000

So, one of my favourite games lately, Timberborn, has released its 1.0 version and finally left early access.

For those who don't know it, Timberborn is a city-building strategy game. In this game, the player takes over the role of a ruler of a beaver colony - after humans (or hoomans, as they're called in-game) vanished from the face of the planet, the beavers took over. There's resource gathering, taking care of your beavers' different needs, building complex water-based power networks, factories, transportation, etc., etc.

Or, a database, in my case.

There are 3D water physics, different seasons such as droughts, where you need to retain water and bad tides, where new water entering the map is polluted and harmful to beavers.

Since the initial release in 2021, many features have been added.

And the latest update broke the game for me a bit. Because they added automation features. These automation features include various sensors for detecting bad tides, water flow, etc. They even added logic gates and HTTP levers.

Oh no

Oh no indeed. I had to play around with these. This is what they look like in-game:

As you can see, they have a name (in this case “HTTP Lever 1”), a “Switch-on URL” and a “Switch-off URL”.

The idea behind these is that streamers can hook these up to other services, for example, Twitch webhooks. If someone leaves a like, fireworks go off, stuff like that.

But: Who says you can only use one of them?

Do you see where I'm going with this?

Oh no

Oh yes. The game can work with around 1000 of them for some time. Windows said it "had some issues with the system" twice while I was experimenting, so from the very start, this isn't very practical. It doesn't have to be, though.

For every lever, there is one endpoint that turns it on and one that turns it off. No batch processing, sadly, but perhaps there's a mod. Another endpoint returns the state of each lever on the current map. The data looks kind of like this:

[
  {
    "name": "HTTP Lever 829",
    "state": false,
    "springReturn": false
  },
  {
    "name": "HTTP Lever 154",
    "state": true,
    "springReturn": false
  },
  {
    "name": "HTTP Lever 839",
    "state": false,
    "springReturn": false
  },
  {
    "name": "HTTP Lever 164",
    "state": true,
    "springReturn": false
  }
]

With two states, such an HTTP Lever can be thought of as a single bit.

All that is needed is a way to read from and write to them.

The Timberborn web interface: How it works

The idea is that we’re going to convert some user input to JSON, convert that to binary using ASCII encoding and flip each bit one by one. When reading, we read all the lever states at once, rearrange them into a bit sequence, split it into 8-bit chunks, decode them back into characters, and parse the resulting JSON. And voila: A read/write data storage.

Let’s start with a little HTML:

<form method="POST" id="form">
  <div>
    <input type="text" id="title">
  </div>
  <div>
    <textarea id="text"></textarea>
  </div>
  <button type="submit">Store in Timberborn</button>
</form>

<button type="button" id="load">
  Load data from Timberborn
</button>

Now comes the fun part. We start with a bit of scaffolding JS:

const title = document.querySelector('#title')
const text = document.querySelector('#text')
const form = document.querySelector('#form')
const load = document.querySelector('#load')
const chunkSize = 8 // We need this to later split the bits
const numberOfLevers = 1000 // This needs to be the exact number of levers in-game, otherwise it won't work reliably.

Next, we listen to a form submit and build a JSON string from the two fields:

form.addEventListener('submit', async (event) => {
  event.preventDefault();
  const data = {
    title: title.value,
    text: text.value,
  }

  const json = JSON.stringify(data)

  // ...
})

Once we have this, we can transform this into a series of binary strings:

form.addEventListener('submit', async (event) => {
  // ...

  const json = JSON.stringify(data)

  const asciiEncoded = json.split('')
    .map(c => c.charCodeAt(0))

  const binary = asciiEncoded.map(
    num => num.toString(2).padStart(chunkSize, '0')
  )

  // ...
})

This gives us an array of 8-bit long strings with 0s and 1s:

We next need to join these up and build the large final bit string. We translate those bits into booleans and then API URLs, which we can then call with fetch:

form.addEventListener('submit', async (event) => {
  // ...

  const bits = binary.join('')
    // So there's no leftover data in the registry 
    // at the end of the current data
    .padEnd(numberOfLevers, '0')
    .split('')
    .map(b => b === '1')

  const allUrls = bits.map((bit, key) => 
    `http://localhost:8080/api/switch-${bit ? 'on' : 'off'}/HTTP Lever ${key + 1}`
  )

  await Promise.all(allUrls.map(url => fetch(url)))

  console.log('done!')
})

When saving, this will trigger a total of 1000 HTTP requests to the game's endpoint. No wonder it doesn't like it.

But: It works!

(There's a gif, it may take a few seconds to load...)

Reading data from Timberborn

Next, we need to read data. As we've seen in the example, the lever states can be fetched all at once, but their order is all scrambled up. We can fix that by first loading everything and then sorting. We then translate everything back into a bit string, chunk that up and decode that into ASCII again:

load.addEventListener('click', async () => {
  const response = await fetch('http://localhost:8080/api/levers')
  const json = await response.json()

  const sorted = json.sort((a, b) => {
    const aNumber = Number(a.name.replace('HTTP Lever ', ''))
    const bNumber = Number(b.name.replace('HTTP Lever ', ''))

    return aNumber - bNumber
  })

  const bitString = sorted.map(l => l.state ? '1' : '0')

  const chunks = []

  for (let i = 0; i < bitString.length; i += chunkSize) {
    chunks.push(bitString.slice(i, i + chunkSize).join(''))
  }

  const numbers = chunks.map(c => Number.parseInt(c, 2))
    // We filter out everything that's only 0s, because that's likely garbage-data
    .filter(n => n > 0)
  const letters = numbers.map(n => String.fromCharCode(n))
  const data = JSON.parse(letters.join(''))

  title.value = data.title
  text.value = data.text
})

And that's it!

Technically, this can be considered a cloud storage now. Since Steam uploads save games to the cloud and Timberborn treats HTTP levers as stateful (i.e. it saves their state when saving the game), everything's persistent.

Whoever manages to get more than a measly kilobit of data into Timberborn, please hit me up, I'm pretty certain we can make a Drupal database adapter for this somehow.

(PS: Sorry, not sorry for the AI image. I had to try it eventually!)

(PPS: This post is not sponsored. But Timberborn devs, if you read this, I'm up for way more shenanigans using the automation features :D)

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕! You can also support me directly via Paypal! Or follow me on Bluesky 🦋!

⚠️ Don't try this at home: Add Brainf**k support to your JS app today!

Pascal Thormeier — Sat, 17 Jan 2026 19:00:24 +0000

Dear Mods of dev.to, please bear with me for this one. This post will have a few profanities, as you might guess from the title. However, these profanities are names of packages and actual technical terms. None of these is meant to offend anyone. I’ll try to censor most of them where sensible.

And here we go again. Stuff no one should probably do in production, because it’s either completely and utterly useless, will confuse the living heck out of everyone having to maintain it, or make everyone scream “No” and “Please don’t”.

Esoteric programming languages it is this time. Specifically, Brainf**k, a dialect of Ook! that sadly can't be understood by Orang Utans. And no, I refuse to believe that it's actually the other way around.

Brainf**k is notoriously hard to read. Mostly because its commands are single characters that move the stack pointer by 1, increase or decrease the value it points at by 1, and loop as long as the current stack element the pointer is pointing to is greater than 0.

I've recently written a post about using and creating unplugins where I mentioned adding Brainf**k support and thought to myself:

So here we are. If you ever wanted to build half your app in a cumbersome, convoluted, unreadable way, the time is now! And you can even open-source it and let others do the same, too!

Creating the Unplugin boilerplate

Straightforward. We also need another dependency called "hirnf**k", a library that transpiles out Brainf*k code to JS. For the non-German-speaking folks, the name of the package translates to "brainf*k", so there's that.

So, let's open a terminal and get going:

$ px degit unplugin/unplugin-starter unplugin-bf
bash: px: command not found

Whoops. Typo. Yes, this already started badly.

$ npx degit unplugin/unplugin-starter unplugin-bf 
$ cd unplugin-bf/ && npm i -s hirnfick

Much better.

This creates an unplugin and installs our source-to-source compiler. We'll implement the compilation in the unplugin's src/index.ts file.

For that, let's first look at hirnf**k's documentation. It includes an ESM example we can slightly modify. Here's what the example looks like:

import hirnfick from "https://jspm.dev/hirnfick";

const helloWorldBF = '++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.'
  + '+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.';

try {
  const helloJs = hirnfick.compileToJsWeb(helloWorldBF);
  const runHello = new Function(`${helloJs} return main().output.trim();`);
  console.log(runHello());
} catch (err) {
  console.error(`Error: ${err.message}`);
}

Perfect, right? It creates an executable function and even contains a Hello World in Brainf**k already!

Implementing everything

It's surprisingly straightforward. Luckily, the unplugin starter already gives us most of the boilerplate, we only need to fill in the gaps. Let's look at what the starter brought:

import type { UnpluginFactory } from 'unplugin'
import type { Options } from './types'
import { createUnplugin } from 'unplugin'

export const unpluginFactory: UnpluginFactory<Options | undefined> = options => ({
  name: 'unplugin-starter',
  transformInclude(id) {
    return id.endsWith('main.ts')
  },
  transform(code) {
    return code.replace('__UNPLUGIN__', `Hello Unplugin! ${options}`)
  },
})

export const unplugin = /* #__PURE__ */ createUnplugin(unpluginFactory)

export default unplugin

First, we change the transformInclude function. We want it to check for .bf files instead of the main.ts. While we're at it, we also rename the unplugin and empty the transform function. The options are also not necessary, so let's remove them, too:

// ...
export const unpluginFactory: UnpluginFactory<Options | undefined> = () => ({
  name: 'unplugin-bf',
  transformInclude(id) {
    return id.endsWith('.bf')
  },
  transform(code) {
    return code
  },
})

We're actually almost there already. Next, we actually copy/paste hirnf**k's example unto the transform function and alter it a bit:

import type { UnpluginFactory } from 'unplugin'
import type { Options } from './types'
import hirnfick from 'hirnfick'
import { createUnplugin } from 'unplugin'

export const unpluginFactory: UnpluginFactory<Options | undefined> = () => ({
  name: 'unplugin-bf',
  transformInclude(id) {
    return id.endsWith('.bf')
  },
  transform(code) {
    const transformed = hirnfick.compileToJsWeb(code)

    const wrapped = `export default new Function(\`${transformed} return main().output.trim();\`)`

    return wrapped
  },
})

export const unplugin = /* #__PURE__ */ createUnplugin(unpluginFactory)

export default unplugin

And believe it or not, we're done. We now have Brain**k support in our JS apps via our lovely unplugin.

How it works

Now, how does this work? First, it reads the file's content and passes it as a string (the code parameter) to the transform function. We then tell hirnf*k to compile it to JS. That's, again, a string. That string is then wrapped into another string that contains the standard export default stuff with an inline function. That function returns whatever the compiled Brainf*k code would try to print via the . command, and trims all the whitespace from it.

Let's simplify the Brainf**k code to this bit:

+-.

The compiled JS would look like this:

export default new Function(`let position = 0;
const cells = [0];
let output = '';

function putchar() {
  output += String.fromCharCode(cells[position]);
}

function main() {
  if (cells[position] < 255) {
    cells[position] += 1;
  }
  if (cells[position] > 0) {
    cells[position] -= 1;
  }
  putchar(String.fromCharCode(cells[position]));

  return { cells, output };
}
 return main().output.trim();`)

We can clearly see where the Brainf**k code lives:

+ becomes cells[position] += 1;
- becomes cells[position] -= 1;
. becomes putchar(String.fromCharCode(cells[position]));

Trying it out

Let's try it out! Luckily, the unplugin starter contains a playground that already sets everything up for us.

We create a new file called hello-world.bf and add the Hello World there:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

(I tried syntax highlighting, but... well... you know...)

Next, in the example's main.ts, we import the file and execute the function it returns:

import HelloWorld from './hello-world.bf'

document.body.innerHTML = HelloWorld()

VSCode doesn’t like this in the slightest. Perhaps it knows that we want to run Brainf**k. What it doesn’t know is that .bf files return JS code, it doesn’t know that the unplugin allows that, and it will complain. We don’t care, though. Perhaps someone will eventually write a VSCode plugin to go with our unplugin. You never know.

We then go to the playground, install dependencies and run this thing_

$ cd playground
$ npm i && npm run dev

That'll start the dev server on localhost, which we open in the browser. And lo and behold:

It actually works!

However, please, please do not use Brainf**k in your production app. But if you're brave enough, you may add a few extra things yourself:

Add input support via ,
Add sourcemaps (good luck)
Support Ook!

Why does no one think of the Orang Utans.

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕! You can also support me directly via Paypal! Or follow me on Bluesky 🦋!

The Mythical One-Fits-All Build Tool Plugin 🦄 (It Actually Exists)

Pascal Thormeier — Sun, 11 Jan 2026 13:28:58 +0000

Do you know that feeling when you're building a complex web app and you need some functionality that actually exists, but not for the framework you're using? Or, let's say you're building a library that needs to hook into the build process of your project, you'd like to open source it, and you just so happen to use Vite, but some poor soul out there would need this exact library, but for Webpack instead? Or they use Snowpack? Or Brunch? Or... Gulp?

Ok, perhaps it's not that bad anymore. The wildest times of the JS world are definitely over. You know, the times when build tools and bundlers and frameworks and component libraries sprouted like mushrooms. A classic XKCD comic about competing standards fits pretty well:

You can even read about my own adventures with the niche build tools Brunch and Snowpack in some previous articles I wrote. Both of these tools haven’t received a commit in 4 to 5 years now, so support is minimal at best.

Nowadays, there are still about half a dozen, give or take a few, build tools/bundlers left that are still highly maintained, broadly used, and that are generally accepted as "standard": Webpack, esbuild, Vite, rspack, Rollup, Rolldown, Bun, and some others based on these.

The problem I described initially persists, though: Most of these work in wildly different ways. A Webpack plugin usually doesn't "just work" in Vite and vice versa. And let's not forget esbuild and all the others!

Luckily, there's movement. Not only are people using things resembling "standard tools" by now, but ever more of these are emerging.

Introducing the UnJS ecosystem

One particular group is building off-the-shelf, framework-agnostic packages that work on their own with few to no dependencies: UnJS.

(The UnJS website)

If you’ve built anything with Nuxt, Vue, Vite or thelike, you’ve likely already used some of their tools without even realising. There are some instant classics like:

h3 - a portable and lightweight http server)
citty - a CLI builder
changelogen - a tool for generating changelogs
ofetch - a highly portable fetch replacement
nitro - the very thing that powers most of Nuxt's server-side capabilities

These tools are everywhere. Staying with Nuxt here for a second, it sometimes feels like Nuxt is simply Vue plus a bunch of UnJS packages and some glue code. Excellent work by these people, if you ask me.

These libraries work agnostic of your build tool/bundler, but they don't directly integrate with them. That's where the, at least in my humble opinion, magnum opus of the UnJS team comes in: unplugins.

I know what a plugin is - but what's an unplugin?

Great question!

I could imagine that the UnJS people had a look at some popular build tools and thought, "Most, if not all, of them use some hook system for plugins. Often, these hooks are named similarly. Why not unify them into a single plugin system?"

And that's precisely what unplugin is: A unified system to hook into build tools. Authors of any unplugin only need to define the actual business logic (i.e., what does the plugin actually do), and the unplugin system takes over the rest. It essentially defines a plugin for each supported build system, all of which contain the same logic the author has implemented. Let's compare the "legagcy plugin architecture" to the unplugin approach:

Without unplugin	With unplugin
One codebase per plugin	One logic factory
Tool-specific APIs, lots of reading up on them	Unified hooks, all behaving the same way
Higher maintenance	Lower maintenance

An example using a starter template

So, let's say we want to create a small plugin that replaces one word with another in the user's main.ts file.

To get started, it's advised to use a template. Luckily, the folks over at UnJS have created a starter template for us that we can use by executing these commands:

npx degit unplugin/unplugin-starter my-unplugin
cd my-unplugin
npm i

This will clone the starter repository into a folder called my-unplugin. It creates everything we need for a working unplugin.

And lo and behold, it even includes our basic unplugin already! When we open src/index.ts, we see the following code:

import type { UnpluginFactory } from 'unplugin'
import type { Options } from './types'
import { createUnplugin } from 'unplugin'

export const unpluginFactory: UnpluginFactory<Options | undefined> = options => ({
  name: 'unplugin-starter',
  transformInclude(id) {
    return id.endsWith('main.ts')
  },
  transform(code) {
    return code.replace('__UNPLUGIN__', `Hello Unplugin! ${options}`)
  },
})

export const unplugin = /* #__PURE__ */ createUnplugin(unpluginFactory)

export default unplugin

Now, there's a ton to unpack here. Unplugins are written by creating a factory function that takes a bunch of options. The function returns the unplugin's definition. Using some generic hooks (in this case, transformInclude and transform, we can do all sorts of things. In these hooks, we specify what will be executed when the user's build tool runs them.

transformInclude checks if a given file name (that's what id is) should be transformed in the first place. If true, the transform function then receives the contents of that file and returns a transformed version. In our case, we replace __UNPLUGIN__ with Hello Unplugin!.

So if the user's project's main.ts would look like this:

console.log('__UNPLUGIN__')

The built main.js would look like this:

console.log('Hello Unplugin!')

And how does it now create the build tool specific stuff?

Again, great question! We notice a bunch of other files in the src/ directory. They're named after the build tool they're for, for example, vite.ts, astro.ts, webpack.ts and so on.

Let's have a look at vite.ts:

import { createVitePlugin } from 'unplugin'
import { unpluginFactory } from '.'

export default createVitePlugin(unpluginFactory)

Is it really that simple? Let's look at webpack.ts:

import { createWebpackPlugin } from 'unplugin'
import { unpluginFactory } from '.'

export default createWebpackPlugin(unpluginFactory)

Yup, seems like!

What the unplugin library does here is take the factory and create a plugin from it, with specialised functions. Ideally, we don’t even need to touch these files, ever.

Sounds good - but what can we actually do with this?

Well, the possibilities are endless. Here's a list of all supported hooks:

Hook	Rollup	Vite	webpack	esbuild	Rspack	Farm	Rolldown	Bun
enforce	❌	✅	✅	❌	✅	✅	✅	❌
buildStart	✅	✅	✅	✅	✅	✅	✅	✅
resolveId	✅	✅	✅	✅	✅	✅	✅	✅
loadInclude	✅	✅	✅	✅	✅	✅	✅	✅
load	✅	✅	✅	✅	✅	✅	✅	✅
transformInclude	✅	✅	✅	✅	✅	✅	✅	✅
transform	✅	✅	✅	✅	✅	✅	✅	✅
watchChange	✅	✅	✅	❌	✅	✅	✅	❌
buildEnd	✅	✅	✅	✅	✅	✅	✅	❌
writeBundle	✅	✅	✅	✅	✅	✅	✅	❌

(Source: official unplugin guide)

I want to especially point out three of these hooks:

resolveId - This one's used for resolving file names, i.e. path rewriting, directory aliasing and similar
load - Change how specific files (determined via loadInclude) are loaded. You could potentially even fetch things from a CDN here
transform - Change code directly as a string. Replace, add, remove, compile, whatever you can think of

As you can see, though, not all build tools support all hooks. But that's ok. You usually can find a way to circumvent this or create logic specific to these build tools. I strongly recommend reading the official guide for this.

Here's some ideas from the top of my head:

A plugin that offers compiler macros like CURRENT_YEAR that get replaced at build time
Count all unique paddings and margins in the code base to give the user an overview
Automagic Brainf**k support!

How would a project now use this unplugin

Like any other plugin, mostly. In Vite, for example, a user could do this:

import { defineConfig } from 'vite'
import MyUnplugin from '@my-company/my-unplugin/vite'

export default defineConfig({
  plugins: [
    MyUnplugin(),
  ],
})

Sounds good - are there any real life use cases?

Indeed, there are! The most popular is unplugin-icons, which lets us install almost any icon in any project by installing, configuring, and using it.

Another real-life example is what we’ve built during my time at Liip for the Swiss canton of Basel-Stadt: a design system with an installable plugin that lets other agencies create websites that automatically align with the canton's CI/CD. It does that by providing Tailwind, installing all necessary PostCSS plugins and delivering a ton of prebuilt utilities and CSS components. You can read up on it on Liip's blog!

Sooo, should everyone be writing unplugins now?

As we German-speaking people say: "Jein" (yes-and-no).

My recommendation, based on experience, is that it's sensible for things expected to be used by many different projects, as it gives you the maximum amount of freedom with little to no downsides, aside from being forced to write agnostic code.

Generally, the business logic could even live in its own package. Why not build a library that exports the functionality and use that as a dependency for an unplugin? That way, the library itself is encapsulated, testable and could be used for other purposes and in different contexts, too, even without the need for a build tool.

If you're writing a Vite package for your own project that you're never going to open-source or that doesn't make any sense at all when used without Vite, though, an unplugin seems like overkill or even a hindrance at times.

Nevertheless, what the people at UnJS built here is a fantastic piece of technology! The logical next step is to standardise build tool interfaces, much like Vite and most UnJS packages already do.

Which package do you think would be worth building an unplugin for?

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕! You can also support me directly via Paypal! Or follow me on Bluesky 🦋!

Old School Tech: How to Animate The Classic DVD Logo Bouncing 📀📐

Pascal Thormeier — Thu, 08 Jan 2026 18:29:44 +0000

It's been quite a while since my last post here - 2 years to be precise. And it's been a wild two years, I tell ya. I got married, switched jobs, had some personal issues, a ton of projects, and way too many ups and downs to put them into a tech post intro.

One of my goals for 2026 was to get back into writing and to continue the style of posts and content that I've been producing for many years before my 2-year writing hiatus. I'm working on quite a few posts, actually, but today, we'll start with a relatively slow one. Or something rather old, I should say.

Old? So, no AI?

No. No AI. Quite the contrary. If you've read the title, and I'm sure you did, otherwise you wouldn't have clicked, we're going to build a little something called the "DVD logo animation".

The what?

... please don't tell me I'm that old by now.

There used to be a time when we would rent or buy movies not by clicking on them, but physically acquiring a round shiny object with a hole in the middle: A DVD. DVD used to stand for "Digital Video Disc", but since many companies (and private people) started putting non-movie data on them, the acronym today stands for "Digital Versatile Disc".

To read data off them, we used special devices called "DVD players". Most of them, when you plugged them into your TV and turned them on, would show the DVD logo bouncing around the screen at perfect 45-degree angles. Some people may even remember sitting in front of this thing, waiting for it to bounce right into the corner of the screen.

The inspiration for this came from a way-too-long YouTube session (ironic, isn't it?) where I saw someone build this animation out of Lego.

Let's get coding already!

Alright, alright, enough nostalgia. We start by acquiring the DVD logo as an SVG. Luckily, Wikimedia is just the place to look for that.

We then put it into a small little HTML file:

<div class="screen">
  <svg class="logo" width="100%" height="100%" viewBox="0 0 1058.4 465.84" xmlns="http://www.w3.org/2000/svg">
    <path d="..." fill="#fff"/>
  </svg>
</div>

(I spare you the d value of that path, it's really not the most interesting thing.)

We then add a bit of styling:

body {
  margin: 0;
  padding: 0;
  background-color: #000;
  height: 100vh;
  display: flex;
  align-items: center;
  justify-content: center;
}

.screen {
  background-color: #000;
  border: 3px solid #fff;
  width: 80vw;
  aspect-ratio: 16/9;
}

.logo {
  width: 12vw;
  height: auto;
  position: relative;
  transition: all linear;
  top: 0;
  left: 0;
}

This will add a white rectangle centered on the screen, with the logo placed in the top-right corner. The 12vw just felt right; there's no science or any sort of measurement behind that.

Animating the whole thingie

We're going to do that with plain ol' Vanilla JS. Yes, everything in this post is old school.

Here's the principle: We change the top and left coordinates by 1 pixel per animation frame. CSS will ensure the animation is as smooth as it can be. By adding 1 pixel to the top and left value, the logo will move to the bottom-right at a 45-degree angle.

Once the logo reaches the bottom of the screen, it should bounce back up while continuing to move to the right. This means the value of change for the top coordinate is now -1, not 1.

Once the logo hits the right edge, the left value turns to -1 (since it should bounce). Once it hits the top edge, the top change value is set to 1 again, etc.

We call these values a delta - so, a "rate of change". Initially, since the logo starts in the top left corner of the screen, these deltas are 1:

let topDelta = 1
let leftDelta = 1

Next, we need to define the time between frames. 5ms gives a pretty smooth transition that isn't too fast. We'll use an interval to update the position repeatedly. In there, we first need to get the current top, bottom, left, and right values of the logo.

setInterval(() => {
  const currentTop = parseInt(logo.style.top) || 0
  const currentLeft = parseInt(logo.style.left) || 0
  const currentRight = currentLeft + logo.clientWidth
  const currentBottom = currentTop + logo.clientHeight

  // ...
}, 5)

We can now define the actual animation logic:

  // ...
  if (currentBottom >= screen.clientHeight) {
    topDelta = -1
  }

  if (currentTop <= 0) {
    topDelta = 1
  }

  if (currentRight >= screen.clientWidth) {
    leftDelta = -1
  }

  if (currentLeft <= 0) {
    leftDelta = 1
  }
  // ...

Lastly, we need to update the position:

  // ...
  logo.style.top = currentTop + topDelta + 'px'
  logo.style.left = currentLeft + leftDelta + 'px'
}, 5)

And done! That was a quick one! Let's see it in action:

Now, the nice thing is: This already is fully responsive. You can change your screen size, rotate the screen in CSS, or even resize it. The animation will always work just the same way.

Let's take a moment and appreciate when the DVD logo finally hits that corner!

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕! You can also support me directly via Paypal!

Beating annoying minigames with Java☕ - Or: How to create a smart auto-clicker 🤖🎮

Pascal Thormeier — Mon, 08 Jan 2024 11:49:36 +0000

Last week was slow. After a rather busy holiday season, I felt like I needed to relax a bit (pro tip: do that occasionally; it does help!) and booted up my PS4 for the first time in months. My game of choice was one that I already played ad nauseam when I was a kid: Final Fantasy 10; only I was playing the HD remaster.

Wait, is this a story, or are you coding something today?

There will be code, promise! But to understand what the code is supposed to do, we first need to understand the problem, which is a rather specific one. Bear with me!

As with most RPGs by Square Enix, and with most Final Fantasy parts in general, the end game, right before the final story boss, is where most of the gameplay is hidden. I got there some time ago and started collecting the ultimate gear for all party members, levelling them up, etc., to face a hidden final super boss called "Penance". This can easily take up dozens of hours and includes a lot of repetitive gameplay, but alas. I like numbers going up.

The player must beat a series of minigames to acquire the ultimate gear for all party members. Some of them can be done in half an hour, and others require days of work and perfect button input to beat them, a single wrong input resetting the progress of the minigame so far.

One of these is called "Dodge the Lightning." In a specific region of the game world, called the "Thunder Plains", there are occasional lightning strikes to the player character that stun them for a couple of seconds.

This image of the Thunder Plains is taken from the Final Fantasy Wiki, all rights to their respective owners.)

Lightning is announced by a screen flash of around 400ms (believe it or not, I measured), followed by a roughly 1-second period. The character dodges the lightning if the player hits the cross button within that timeframe.

Now, to beat that minigame, the player needs to dodge 200 (two hundred) lightning strikes. In succession. Without a single mistake. In one go.

Ugh.

Right? The most I've managed was 47. The frustration was real. I was already spending hours waiting for a flash of light blue on the screen and pressing the button at the right moment. If a single car outside drew my attention a little too much, I missed the time window and had to start over.

This wasn't fun anymore. Or relaxing. At all.

I got up to get a coffee (haha, in a Java post, get it? Just kidding, I actually did get a coffee...) and started thinking: If this challenge is so dull and not fun, how could I alter it to make it more fun and fit my skill set better? I'm not used to precision work for hours on end.

So, if I can't do it, perhaps a machine can?

Opening up the borders

First challenge: How was I supposed to execute anything on the PS4? Running custom software on a console is tricky, and I did not want to tamper with my beloved PS4 too much. I didn't want to lose any game progress or, worse, brick it entirely. So, running software on the console was out.

Luckily, Sony has this nifty thing called "Remote Play" that lets users connect to their console using a computer (as if the console isn't a computer). The screen output is then visible in a window on the computer and can be interacted with.

For example, streamers on Twitch and YouTube do that a lot. Installing streaming software on a PS is more tedious than using an existing setup, grabbing the screen and streaming that.

However, there is a little issue: Remote Play no longer allows cross-button input in the latest build.

So I used Chiaki instead.

Chiaki is a Remote Play protocol client and allows any button input. Even with custom key mapping. Perfect!

Letting the machine do the job

Once I played PS on my PC (this sentence alone was already an adventure), I got to coding. I needed to detect the screen flash and get the timing just right to press the cross button, which I mapped to the "Enter" key.

I decided on Java since Java's AWT has a built-in class called "Robot" that does exactly what I wanted.

Step one was to figure out where to take a sample from. I decided to use the centre of the screen since I would put the PS4 Chiaki window roughly there anyway:

(Note: I'm leaving out any import statements since this is bog-standard Java stuff that doesn't require any additional dependency.)

public class Main
{
  public static void main(String[] args) {
    try {
      Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
      double width = screenSize.getWidth();
      double height = screenSize.getHeight();
      int sampleX = (int) width / 2;
      int sampleY = (int) height / 2;

      //More code later

    } catch (Exception e) {
      System.out.println("Oh noes: " + e.getMessage());
    }
  }
}

Now, I needed the Robot to sample the screen and repeatedly wait for a specific brightness. Through trial and error (quite literally), I figured that a brightness value of 75% was ideal. The screen would get bright quickly for about a frame or two, every other frame is either build-up (brightness increasing) or fade-out (brightness decreasing).

public class Main
{
  public static void main(String[] args) {
    try {
      Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
      double width = screenSize.getWidth();
      double height = screenSize.getHeight();
      int sampleX = (int) width / 2;
      int sampleY = (int) height / 2;

      Robot robot = new Robot();

      while (true) {
        Color c = robot.getPixelColor(sampleX, sampleY);
        float[] hsbColor = Color.RGBtoHSB(c.getRed(), c.getGreen(), c.getBlue(), null);

        if (hsbColor[2] > 0.75) {
          // Screen flash detected, time to spam-click!
        }

        Thread.sleep(16);
      }
    } catch (Exception e) {
      System.out.println("Oh noes: " + e.getMessage());
    }
  }
}

Perfect. This was already working quite reliably.

We're using the HSB colour space (which stands for "Hue, Saturation, Brightness") to determine the brightness value.

I've explained the HSB (or HLS in some cases) in my post on how to create a rainbow from scratch 🌈📐.

In Java, a Color object is always in the RGB (Red, Green, Blue) colour space, whereas the static function RGBtoHSB returns a float array that contains the hue of the colour at index 0, the saturation at index 1 and the brightness at index 2. The brightness value is between 0 and 1, indicating a percentage.

I also added a sleep of 16ms to the loop to prevent wasting CPU cycles on checking frames that didn't change. Chiaki allows setting the frames per second (FPS) of the mirrored screen, which was either 30 or 60. To get the timing right, I needed 60 FPS. A second has 1000 milliseconds. At 60 FPS, every frame is up for roughly 16-17ms.

This code detected all of the screen flashes, and through the magic of debugging, I was confident that I wouldn't miss any of the lightning strikes.

Last but not least, I needed to add the actual button press. Luckily, the Robot class can do that too:

public class Main
{
  public static void main(String[] args) {
    try {
      Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
      double width = screenSize.getWidth();
      double height = screenSize.getHeight();
      int sampleX = (int) width / 2;
      int sampleY = (int) height / 2;

      Robot robot = new Robot();

      int dodged = 0;
      while (true) {
        Color c = robot.getPixelColor(sampleX, sampleY);
        float[] hsbColor = Color.RGBtoHSB(c.getRed(), c.getGreen(), c.getBlue(), null);

        if (hsbColor[2] > 0.75) {
          Thread.sleep(120); // Simulates reaction time of a really _really_ fast human.
          for (int i = 0; i < 14; i++) {
            robot.keyPress(KeyEvent.VK_ENTER);
            Thread.sleep(50); // More or less the lower bound of the average length of a key press.
            robot.keyRelease(KeyEvent.VK_ENTER);
            Thread.sleep(50); // A little waiting time between releasing the button and pressing it again.
          }

          dodged++;
          System.out.println("Dodged: " + dodged);
        }

        Thread.sleep(16);
      }
    } catch (Exception e) {
      System.out.println("Oh noes: " + e.getMessage());
    }
  }
}

So, what happens here precisely? Once a lightning strike is detected, we wait for around 120ms, which simulates a ridiculously fast human, and then we spam-click the "Enter" button. Since the Robot class method keyPress is actually a keyDown, we also need to call keyRelease because it otherwise registers as a continuous button press.

This, however, lets us steer the duration of the key press. Some sources suggest that the average key press is between 50 and 300ms for humans, so I figured if the Robot is already reacting at twice the average human reaction speed, why not give it super-human button-pressing abilities as well?

Last but not least, the spam-clicking is essential here. If the network connection or Chiaki has a bit of delay, the spam-clicking guarantees that at least one button press gets through to the game.

A word of caution: Beware of auto-clickers

During development, I once made the mistake of opening a different window with a white background. White means a brightness of 100%, which is larger than 75%, which means spam-clicking Enter.

Needless to say, this almost wreaked havoc by constantly pressing Enter. It started all sorts of other apps, basically behaving like a fork bomb after mere seconds. My CPU almost melted. And worst of all, I missed a lightning strike and had to start over.

So, did the auto-clicker work in the end?

Yes. And just for the flex, I dodged 222 lightning bolts.

Take that, game!

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕! You can also support me directly via Paypal!

Coding with crustaceans?🦐 - CodeLobster IDE🦞 review

Pascal Thormeier — Tue, 19 Dec 2023 10:36:14 +0000

You probably know how much I like to try new things. I've published several posts about how I tried new tools, such as Snowpack, and have built stuff that probably shouldn't exist, such as Linear Regression in Scratch, or everyone's favourite monstrosity, Cascading Server Sheets.

However, rarely have I touched my toolchain. Especially my IDE. So, when I was approached by the team over at CodeLobster Software, I figured I should give this tool a try! So here's a review of CodeLobster IDE!

Disclaimer: This post is sponsored by CodeLobster IDE, but I'll give it an honest review nevertheless. To me, delivering value to you is important, so if you think this tool looks interesting, give it a shot!

The best way to figure out if a tool works is to actually use it. CodeLobster IDE has built-in support for a ton of frameworks, including, but not limited to, Symfony, Drupal, Angular, React, Vue, Magento and Laravel, so the web devs out there should feel at home.

For this review, I've built a small Symfony app that would require the user to enter their location and get a weather forecast from an API. I won't go much into the details of this process, but I'll talk about the things I encountered along the way.

Installing the IDE

First things first: Let's acquire the tool. We can download CodeLobster IDE on their website, http://www.codelobsteride.com. They offer versions for Windows, Linux (both .rpm and .deb packages), and MacOS. There is a free tier, but they're currently (as of November 2023) offering discounts on their Pro versions as well.

In this post, we'll work with the Pro version on Arch Linux (I use Arch, btw) to cover as many of the features as possible.

The first glance

The IDE itself is relatively simple. It resembles most other IDEs, which I don't find surprising. After all, the concept has worked so far, so why change it? It doesn't have any extra bells and whistles so far. Although the icons could use a bit of a brush-up, the overall look is tidy.

When we look at the second row of icons, we see things like a paragraph, an image, a table, the letter J, a colour palette, a line feed, and much more.

Turns out, when we create a fresh new HTML file, these icons are shortcuts for often-used elements!

Clicking on them directly adds the code to the HTML file:

Now I wonder two things: a) Can I customize these, and b) are there keyboard shortcuts? But for the moment, I think I digress.

However, my eyes feel a bit sore. CodeLobster IDE has a bunch of presets for the entire visual style of the app. Some look better than others, but that's a preference. For the nostalgic devs among us, there's even a theme called "Eclipse". And boy, oh boy, do I not like that theme. Brings back some of the not-so-desired memories.

However, I'll stick to the "AtomOne Dark" theme for the rest of this post.

Creating a project

Now that we've eased my random-button-pressing urges let's start with the project. When Clicking on "File", hovering "New", and clicking on "Project", CodeLobster IDE greets me with a simple form. It lets me select the framework, if any, the location, and a name. It even shows me a "Project URL for debugging (F5)", which I'm intrigued to check out. After all, F5 is also only just a button.

Selecting the "Symfony" framework continues the wizard. I can either create a project based on version 5.x or 4.4 of the framework. Clicking on "Next" asks for some sensible defaults, such as the installation type, which project template to use, if I want a database, and, if so, how to connect to it. Once done, I click on "Finish", and the IDE starts rolling the setup.

It installs Symfony and opens up the project folder. Nice! This is a feature I lack from most IDEs I've used so far: A sensible default set of frameworks that just work. Some IDEs offer some boilerplates, but to specifically create a Symfony, Laravel or Drupal project, you'd need to do most of the setup yourself or install extra plugins.

Language support

First things first: I want to look at something. Ideally, something served by Symfony. So I create a PHP file in src/Controller called HomeController.php.

The PHP template itself is minimal, offering an opening and a closing tag. Given, the templates can be edited, but what I'm missing a bit here are custom templates or more sophisticated templates, such as class files that could automatically determine the namespace and such.

Once done importing the necessary dependencies, such as an entity, the AbstractController class, and the class TextType to build the form, I start to create the form.

The auto-complete feature is rather decent, offering IntelliSense and dedicated Symfony support, although only in the Pro version.

Once done with the controller, I create a Twig file to render it. Again, the Twig support is decent! The syntax highlighting works very well (even a little more detailed than with some editors and IDEs), and I finally get to use the shortcut buttons mentioned earlier!

YAML support works well, too, although I'd wish for a bit more of the Ctrl + click support that I'm so used to from any JetBrains IDE. For example, when defining routes, I'd really like to be able to Ctrl+click on the fully qualified class name and jump to the respective file.

After building the thing

To be honest, I need to get used to CodeLobster IDE. Coming from another editor makes things a little difficult, but that's to be expected.

In general, I had a great time building with this IDE, and CodeLobster has supported me well along the way. I think though, some features are either missing or I haven't found them. For example, I'm missing standard auto-save a bit. But what I think I miss most is the ability to Ctrl+click absolutely everything. From file paths to classes and variables. Sometimes, it allows Ctrl+click on things that I don't think are supposed to be clickable, such as a (bool) typecast that leads to an environment configurator from Symfony itself.

What surprises me the most is the balance of features the developers of CodeLobster IDE have found. This is very subjective, but to me, it feels less cluttered and overloaded than, say, PHPStorm or Eclipse (if anyone out there actually still uses Eclipse, that is) but more complete than Visual Studio Code with a bare installation.

Using the built-in Symfony support of the Pro version had another advantage: There's an extra GUI for commands with a tree-like browser.

This nifty little tool helps to gain an overview of which commands actually exist and what they do. Instead of going through them one by one on the CLI, a simple click shows you the expected arguments and what the command does.

Drupal, for example, also offers a "Create module" functionality - something that's usually a bit tedious. I'd wish they would add more of these functionalities for other frameworks, such as Vue or Nuxt.

The ecosystem

During my journey to building the app, I found myself looking for advice on A Popular Search Engine™ pretty often. The one thing that kept popping up was the CodeLobster IDE forums. The community is pretty active, with a total of around 26 thousand registered members, roughly 2800 topics and 10 thousand posts.

There are dedicated subforums for support, advice and desires, and news about CodeLobster IDE and the company behind it. The CodeLobster IDE team is active in the forum and answers questions. The community itself seems welcoming and very much on the topic.

And let's be real here: An oldschool phpBB board? That brings back good old memories, doesn't it?

Summary

The IDE itself works. It works really, really well; it's just the developers' decisions on some of the details that may cause some frustration if you're used to some other editor. Unfortunately, the IDE doesn't offer very much customization for those things, but if you're going to rebuild another IDE entirely with customization, why switch in the first place?

I found a pitfall or two (I needed to explicitly set where it could find the PHP executable, for example), but those aren't game-breakers at all.

So, if you're looking for a new IDE, give CodeLobster a try. There's a free version, and once you're used to it, try out the Pro version!

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!

⚠️ Don't try this at home: A CMS written in Bash ONLY??

Pascal Thormeier — Sun, 03 Sep 2023 17:02:26 +0000

Here we go again.

After building an image modal with CSS only (and completely neglecting accessibility (sorry, @grahamthedev)) and an attempt to establish CSS as a backend language (although it worked, you people didn't like it very much for some reason. I wonder why.), we're finally back with stuff you and I probably shouldn't ever do.

Today: Let's use Bash (yes, Bash) to create a CMS!

Pascal no

Pascal yes! Pascal always yes!

To give credit where credit is due: This idea came from a funny discussion with a co-worker about how to overcomplicate stuff. He came up with a "bash server", and we started to exaggerate it more and more until I said, "Challenge accepted," and here we are.

Disclaimer: We'll neglect security, apart from some password encryption and most best practices. This tool will be something I'll never ever ever use in production, and you, dear reader, should not do it either. Please. There. You've been warned.

Defining what it does

We'll create a very basic CMS:

A user can log in and log out (so we need users and session handling)
A logged-in user can create, update and delete pages
An anonymous user can read all pages
A page consists of a navigation title, a route path, some markup and a flag if it should show up in the main navigation

However, to use Bash as a backend language, we first need to get it to handle HTTP requests. Luckily, there are Bash utilities we can use to listen to TCP requests and send responses, most notably netcat. We "only" need to parse a request and generate a response.

Once that's working, we'll use SQLite to load the requested page and render its markup.

Let's move on to the first bits of code.

The database schema

The boring bits first. We'll use the following database schema for our SQLite database and add a few default records:

CREATE TABLE IF NOT EXISTS pages (
  routePath TEXT NOT NULL,
  navTitle TEXT,
  isInMainNavigation BOOLEAN NOT NULL,
  markup TEXT NOT NULL
);

INSERT INTO pages VALUES
('/', 'Home', 1, '<h2>Hello, Bash CMS!</h2>'),
('/about', 'About', 1, '<h2>About</h2><p>This page was created entirely with BashCMS!</p> <p><a href="/about/bash-cms">Learn more</a></p>'),
('/about/bash-cms', NULL, 0, '<h2>About BashCMS</h2><p>BashCMS is a CMS entirely written in Bash!</p>');

CREATE TABLE IF NOT EXISTS users (
  username TEXT NOT NULL,
  password TEXT NOT NULL /* Hash generated with sha256sum */
);

INSERT INTO users VALUES
('admin', 'fc8252c8dc55839967c58b9ad755a59b61b67c13227ddae4bd3f78a38bf394f7'); /* pw: admin */

CREATE TABLE IF NOT EXISTS sessions (
  sessId TEXT NOT NULL,
  userRowId INTEGER
);

We can access the database via the sqlite3 CLI tool, which we can feed with data from our Bash script.

The actual server

Let's start with the Bash part now. To listen to HTTP requests, we use Netcat. We'll be using the OpenBSD Netcat version.

In the listen mode, Netcat is interactive. It prints out the request details (i.e. the headers, the body, the HTTP method and all) on STDOUT and expects the user to write the response in the STDIN.

For those unfamiliar with Linux/Bash, STDIN and STDOUT are the default ways to communicate with a program. What we see in the terminal is usually STDOUT, and the keyboard input is STDIN. A program is allowed to read from STDIN and write to STDOUT.

Once we send something to Netcat, it sends that over the wire and terminates. This means that we can only handle a single request at a time. For the server to run continuously, we need to start Netcat again and let it listen after it has terminated.

To read and write from Netcat, we also need a way to programmatically read STDOUT and write to STDIN. We can do this using a utility called coproc, which executes a given command asynchronously in a subshell. We do nothing as long as Netcat is waiting for some incoming requests. Only once Netcat starts to write to the STDOUT do we start reading and save it to a variable.

There is, however, one small problem: Netcat does not tell us if and when it's finished writing to STDOUT. We need to determine that ourselves. The most straightforward approach is to wait for an empty new line and stop there.

We basically end up with a structure like this:

while true # You know your script will be fun when it starts with an endless loop.
do
  coproc nc -l -p 1440 -q1 -v # Spawns netcat such that we can read from and write to it

  REQ_RAW="" # This will contain the entire request
  IFS="" # Delimiter for `read`

  while read -r TMP; do # Read every line from STDOUT
    REQ_RAW+=$TMP$'\n' # Append the line to the REQ variable

    # If the length of TMP is equal to one byte
    if [[ ${#TMP} -eq 1 ]] ; then
      break
    fi
  done <&"${COPROC[0]}" # Reads from the coproc STDOUT, line by line

  echo $REQ_RAW # Output the request for testing purposes

  kill "$COPROC_PID" # Kill the process for the subsequent request
  wait "$COPROC_PID" # Wait until it's actually gone
done

If you're really unfamiliar with Bash, this looks intimidating. It might even do so for people who know Bash. I learned a lot during this experiment, and I am deeply convinced that Bash works very much like quantum physics: One does not understand Bash; one gets used to it.

Back to business... The "empty line" approach breaks down as soon as we want to read the HTTP body in case of a POST request. Luckily, HTTP knows a header called Content-Length that tells us the exact number of bytes.

This blows up the code for our server tremendously:

while true
do
  coproc nc -l -p 1337 -q1 -v # Spawns netcat such that we can read from and write to it. Listens on port 1337.

  REQ_RAW="" # This will contain the entire request
  IFS="" # Delimiter for `read`

  while read -r TMP; do
    REQ_RAW+=$TMP$'\n' # Append the line to the REQ variable

    TMPLEN=$(echo $TMP|wc -c) # Figure out the length of $TMP in bytes

    # Deduct the length of the read bytes from the rest of the body length
    if [[ $BODYLENGTH -ge 0 ]]; then # Still some body left to read
      BODYLENGTH=$((BODYLENGTH - TMPLEN))
    fi

    # If the request has a body (determined by the header, which is usually the last one)
    # We continue reading the exact number of bytes
    if [[ "$TMP" =~ ^"Content-Length: " ]]; then
      BODYLENGTH=$(echo "$TMP"|grep -o '[[:digit:]]\+')
      HAS_BODY=1
    fi

    # Read the entire body; abort reading
    if [[ $HAS_BODY -eq 1 ]] && [[ $BODYLENGTH -le 0 ]]; then
      break
    fi

    # No body but empty line encountered, abort reading
    if [[ $HAS_BODY -eq 0 ]] && [[ $TMPLEN -le 2 ]]; then
      break
    fi
  done <&"${COPROC[0]}" # Reads from the coproc STDOUT, line by line

  # Display the entire request for debugging
  echo $REQ_RAW

  kill "$COPROC_PID" # Kill the process for the subsequent request
  wait "$COPROC_PID" # Wait until it's actually buried
done

This works well already. We basically have a request logger now. Progress!

The anatomy of a HTTP request

We first need to parse the request to determine what the server should execute. Let's look at what we're dealing with.

A typical HTTP request is structured like this:

[Method] [Path + Query String] HTTP/[HTTP Version]
[Headers]

[Body]

When I perform a GET request on the server, it outputs something like this:

GET / HTTP/1.1
User-Agent: PostmanRuntime/7.29.0
Accept: */*
Cache-Control: no-cache
Host: localhost:1440
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

A POST request, on the other hand, could look like this:

POST / HTTP/1.1
User-Agent: PostmanRuntime/7.29.0
Accept: */*
Cache-Control: no-cache
Host: localhost:1440
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: multipart/form-data; boundary=--------------------------328683080620751780512479
Content-Length: 169

----------------------------328683080620751780512479
Content-Disposition: form-data; name="hello"

world
----------------------------328683080620751780512479--

We can work with this.

Adding some logic

The request is stored as a single string in a variable called REQ_RAW, so we can parse it using several other Bash utilities.

We create a function called parse_request and put that into a separate file to keep things organized. We then call this function after the reading loop:

#!/usr/bin/bash

source ./server/parse_request.sh

while true # Continue doing this, kind of like an event loop.
do
  coproc nc -l -p 1440 -q1 -v # Spawns netcat such that we can read from and write to it

  ## ...

  # Declare an associative array called `REQUEST`
  declare -A REQUEST=()

  parse_request $REQ_RAW REQUEST

  # Print the contents of the associative array
  declare -p REQUEST

  # Add more magic here

  kill "$COPROC_PID" # Kill the process for the subsequent request
  wait "$COPROC_PID" # Wait until it's actually gone
done

This function needs to do a few things at once:

Determine the HTTP method
Determine the route the user has requested
Parse out any GET variables (i.e. ?foo=bar, etc.)
Parse out the body
Parse out cookies

We can parse the very first line of the request to get the HTTP method and route path. Afterwards, we parse the cookies and check if we need to parse a body, which only happens on POST and PUT requests.

#
# Parses the entire request
#
function parse_request() {
  RAW_REQ=$1

  # This makes the REQUEST associative array available to write to
  # We need to make sure to not call it REQUEST, though, because
  # that name is already reserved in the outer scope
  declare -n INNER_REQ="$2"

  # Extract the request line: method, path (+ query string) and version
  REQUESTLINE=`echo "${RAW_REQ}" | sed -n 1p`
  IFS=' ' read -ra PARTS <<< "$REQUESTLINE"
  METHOD=${PARTS[0]}
  REQUEST_PATH=${PARTS[1]}

  # Split query string from the actual route
  IFS='?' read -ra REQUEST_PATH_PARTS <<< "$REQUEST_PATH"
  REQUEST_ROUTE=${REQUEST_PATH_PARTS[0]}
  QUERY_STRING=${REQUEST_PATH_PARTS[1]}

  if [[ "$QUERY_STRING" != "" ]]; then
    parse_query_string $QUERY_STRING INNER_REQ
  fi

  parse_cookies $RAW_REQ INNER_REQ

  # If we're dealing with either a POST or a PUT request, chances are there's a form body.
  # We extract that with the previously found $FORMDATA_BOUNDARY.
  if [[ "$METHOD" == "POST" ]] || [[ "$METHOD" == "PUT" ]]; then
    parse_body $RAW_REQ INNER_REQ
  fi

  INNER_REQ["METHOD"]="$METHOD"
  INNER_REQ["ROUTE"]="$REQUEST_ROUTE"
}

The query string parsing is pretty straightforward:

#
# Parses the query string and assigns it to the request object
#
function parse_query_string() {
  RAW_QUERY_STRING=$1
  declare -n REQ_ARR="$2"

  # Split the query parameters into a hashmap
  IFS='&' read -ra QUERYPARTS <<< "$QUERY_STRING"
  for PART in "${QUERYPARTS[@]}"; do
    IFS='=' read -ra KEYVALUE <<< "$PART"
    KEY=${KEYVALUE[0]}
    VALUE=${KEYVALUE[1]}
    REQ_ARR["QUERY","$KEY"]="$VALUE"
  done
}

And so is the cookie parsing:

#
# Parses cookies out of the request headers
#
function parse_cookies() {
  RAW_REQ_BODY=$1
  declare -n REQ_ARR="$2"

  COOKIE_LINE=`echo $RAW_REQ_BODY|grep 'Cookie:'`
  COOKIE=${COOKIE_LINE#"Cookie:"}

  if [[ "$COOKIE" != "" ]]; then
    IFS=';' read -r -d '' -a COOKIEPARTS <<< "$COOKIE"

    for PART in "${COOKIEPARTS[@]}"; do
      if [[ "$PART" != "" ]]; then
        IFS='=' read -ra KEYVALUE <<< "$PART"
        KEY=${KEYVALUE[0]//" "/""} # Remove all spaces, so we don't have leading spaces
        VALUE=${KEYVALUE[1]}
        REQ_ARR["COOKIE","$KEY"]=${VALUE::-1}
      fi
    done
  fi
}

In both functions, we carefully rip the necessary parts out of the entire request and split it by some characters, namely ? and = for the query string and ; and = for the cookies. We then remove some unnecessary spaces and write it to the REQUEST associative array.

Parsing the body is more complex. We're dealing with the multipart/form-data format to allow for multi-line strings and, potentially, file uploads. I found it actually more straightforward to work with than any URL encoding.

#
# Parses the POST body and assigns it to the request object
#
function parse_body() {
  RAW_REQ_BODY=$1
  declare -n REQ_ARR="$2"

  FORM_BOUNDARY_LINE=`echo $RAW_REQ_BODY|grep 'Content-Type: multipart/form-data; boundary='`
  FORM_BOUNDARY=${FORM_BOUNDARY_LINE#"Content-Type: multipart/form-data; boundary="}

  # Replace the $FORMDATA_BOUNDARY with a single character so we can split with that.
  TMP_BODY_PARTS=`echo "${RAW_REQ_BODY//"$FORM_BOUNDARY"/$'§'}" | head -n -2` # We need to use _some_ character to use `read` here.

  IFS='§' read -r -d '' -a BODYPARTS <<< "$TMP_BODY_PARTS"

  for PART in "${BODYPARTS[@]}"; do
    KEY=`echo "${PART}" | grep -o -P '(?<=name=").*?(?=")'`
    if [[ "$KEY" != "" ]]; then
      VALUE=`echo "${PART}" | head -n -1 | tail -n +4`
      REQ_ARR["BODY","$KEY"]=${VALUE::-1}
    fi
  done
}

When we run the code now with our GET request from before, we get the following output from our Bash server:

declare -A REQUEST=([ROUTE]="/" [METHOD]="GET" )

(Yes, declare -p creates a declare -A statement, so one could execute that again to have the same associative array.)

The mentioned POST request would output this:

declare -A REQUEST=([BODY,hello]="world" [ROUTE]="/" [METHOD]="POST" )

Neat!

Reacting to the request

Similar to the REQUEST array, we declare a RESPONSE array. This array will contain the DOM we deliver, the status code, and some headers, like Set-Cookie or Location for redirects.

Since we need to be able to tell users apart (some are logged in and some are not), we implement a function called set_session. This generates a session ID, writes it to the SQLite database, and sets a session cookie. Any following request from the same client will send that same session ID cookie.

function set_session() {
  declare -n REQ="$1"
  declare -n RES="$2"

  if [[ "${REQ[COOKIE,SESSID]}" != "" ]]; then
    # SESSID cookie was already set once; reset it
    RES["COOKIES,SESSID"]="${REQ[COOKIE,SESSID]}"
  else
    # No SESSID cookie, so let's generate one
    SESSID=`echo $RANDOM | md5sum | head -c 20; echo;` # Taken from SO.

    # Save cookie into database
    sqlite3 db.sqlite "insert into sessions values ('${SESSID}', NULL);" ".exit"
    RES["COOKIES,SESSID"]="$SESSID"
  fi
}

Notice how we need both the REQ and the RES array: We already write to the RESPONSE array by setting a COOKIES key with a sub-key called SESSID.

We call this function after we call parse_request:

while true; do

  # Request reading shenanigans

  declare -A REQUEST=()
  declare -A RESPONSE=()
  parse_request $REQ_RAW REQUEST

  set_session REQUEST RESPONSE

  # More stuff later, don't worry

  kill "$COPROC_PID" # Kill the process for the subsequent request
  wait "$COPROC_PID" # Wait until it's actually gone
done

Next, we can implement a function to react to the actual request. We call it render_cms_page. In there, we look in the database for any entry with a route that matches the route from the request:

function render_cms_page() {
  REQUEST=$1
  declare -n RES="$2"

  DOM=`sqlite3 db.sqlite "select markup from pages where routePath='${REQUEST[ROUTE]}';" ".exit"`

  if [[ "$DOM" == "" ]]; then
    RES["BODY"]=`render_response "Not found."`
    RES["STATUS"]="404 Not found"
  else
    RES["BODY"]=`render_response $DOM`
    RES["STATUS"]="200 OK"
  fi
}

You might notice the render_response function in there, too. We use that to generate all of the surrounding HTML, such as a page header and navigation and some CSS:

function render_response() {
  DOC_START=`doc_start $1`
  PAGE_HEADER=`page_header`
  DOC_END=`doc_end`

  cat <<EOF
    $DOC_START
    $PAGE_HEADER

    <main>
    $2
    </main>

    $DOC_END
EOF
}

In there, however, we have the functions doc_start, page_header and doc_end:

function doc_start() {
  cat <<EOF
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <title>$1</title>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/jgthms/minireset.css@master/minireset.min.css">
    <style>
      * { font-family: monospace; font-size: 16px; }
      h1 { font-size: 1.5rem; font-weight: bold; }
      h2 { font-size: 2rem; font-weight: bold; margin-bottom: 0.5rem; }
      p { margin-bottom: 0.5rem; }
      header { padding: 1rem; border-bottom: 1px solid #000; }
      main { padding: 1rem; }
      nav ul { margin-top: 1rem; display: flex; gap: 1rem; }
      label { display: block; }
    </style>
  </head>
  <body>
EOF
}

function doc_end() {
  cat <<EOF
  </body>
</html>
EOF
}

function page_header() {
  # Fetch header-relevant pages
  cat <<EOF
  <header>
    <h1>Bash CMS</h1>
    <nav>
      <ul>
EOF
  while read -r PAGE_ROW; do
    IFS='|' read -r -d '' -a PAGE_PARTS <<< "$PAGE_ROW"
    NAV_TITLE=${PAGE_PARTS[0]}
    ROUTE_PATH=${PAGE_PARTS[1]}
    cat <<EOF
        <li><a href="$ROUTE_PATH">$NAV_TITLE</a></li>
EOF
  done <<< `sqlite3 db.sqlite "select navTitle, routePath from pages where isInMainNavigation=1;" ".exit"`

  LOGGEDIN_USERID=`sqlite3 db.sqlite "select userRowId from sessions where sessId = '${REQUEST[COOKIE,SESSID]}'" ".exit"`
  if [[ "$LOGGEDIN_USERID" == "" ]]; then
    cat <<EOF
      <li><a href="/login" class="login">Login</a></li>
EOF
  else
    cat <<EOF
        <li><a href="/add-new-page" class="login">Add new page</a></li>
        <li><a href="/logout" class="login">Logout</a></li>
EOF
  fi
  cat <<EOF
    </ul>
  </header>
EOF
}

And with that, we're almost done.

The last step to an actual response is to render a response string. Much like an HTTP request, a response is a single multi-line string with different parts. We only need to assemble it correctly:

function generate_response_string() {
  declare -n RES="$1"

  # Transform cookie entries into Set-Cookie headers
  COOKIES=""
  for RESKEY in "${!RES[@]}"; do
    if [[ "$RESKEY" =~ ^"COOKIES," ]]; then
      COOKIE_NAME=${RESKEY#"COOKIES,"}
      COOKIES+="Set-Cookie: $COOKIE_NAME=${RES[$RESKEY]}
" # Adds a newline after this Set-Cookie header.
    fi
  done

  RES["CONTENT_TYPE"]="text/html"
  RES["HEADERS","Content-Type"]="${RES[CONTENT_TYPE]}; charset=UTF-8"
  RES["HEADERS","Server"]="Bash. Please don't send cat /etc/passwd as a cookie because hacking is bad :("

  HEADERS=""
  for RESKEY in "${!RES[@]}"; do
    if [[ "$RESKEY" =~ ^"HEADERS," ]]; then
      HEADER_NAME=${RESKEY#"HEADERS,"}
      HEADERS+="${HEADER_NAME}: ${RES[$RESKEY]}
" # Adds a newline after this Set-Cookie header.
    fi
  done

  # declare -p RES

  cat <<EOF
HTTP/1.1 ${RES[STATUS]}
${COOKIES::-1}
${HEADERS}

${RES[BODY]}
EOF
}

And we're good to go. Let's see what this does:

(On a side note: Using backticks anywhere is making me nervous now. Who knows what it'll execute...)

Adding the routes

Now that we've implemented the dynamic routes let's take care of the static ones, such as /login, /edit, /add-new-page, /logout and /delete. For that, we add two more functions: One for the login form and one for the edit form:

function render_login_page() {
  cat <<EOF
  <form method="POST" action="/login" enctype="multipart/form-data">
    <label for="username">User name</label>
    <input type="text" name="username" id="username" value="$1">

    <label for="password">Password</label>
    <input type="password" name="password" id="password">

    <button type="submit">Login</button>
  </form>
EOF
}

function render_edit_form() {
  NAVTITLE=$1
  IS_IN_MAIN_NAVIGATION=""
  ROUTEPATH=$3
  DOM=$4

  if [[ "$2" == "1" ]]; then
    IS_IN_MAIN_NAVIGATION=" checked"
  fi

  cat <<EOF
  <form method="POST" enctype="multipart/form-data">
    <label for="navtitle">Navigation title</label>
    <input type="text" name="navtitle" id="navtitle" value="$NAVTITLE">

    <label for="routepath">Route path</label>
    <input type="text" name="routepath" id="routepath" value="$ROUTEPATH">

    <label for="is_in_main_navigation">
      Is it in navigation?
      <input type="checkbox" value="1" name="is_in_navigation"$IS_IN_MAIN_NAVIGATION>
    </label>

    <div>
      <label for="dom">Content</label>
      <textarea name="dom" id="dom" style="width: 100%; height: 300px;">$DOM</textarea>
    </div>

    <button type="submit">Save</button>
  </form>
EOF
}

And lastly, we expand the render_cms_page function:

function render_cms_page() {
  REQUEST=$1
  declare -n RES="$2"

  if [[ "${REQUEST[ROUTE]}" == "/login" ]]; then
    if [[ "${REQUEST[METHOD]}" == "POST" ]]; then
      USERNAME=${REQUEST[BODY,username]}
      PASSWORD=`echo ${REQUEST[BODY,password]} | sha256sum`
      USERID=`sqlite3 db.sqlite "select rowid from users where username='$USERNAME' and password='${PASSWORD::-3}'"`

      if [[ "$USERID" == "" ]]; then
        DOM=`render_login_page $USERNAME`
        DOM+="<p>Username or password incorrect</p>"
        RES["BODY"]=`render_response "Login" $DOM`
        RES["STATUS"]="200 OK"
      else
        sqlite3 db.sqlite "update sessions set userRowId = $USERID where sessId = '${REQUEST[COOKIE,SESSID]}'"
        RES["STATUS"]="307 Temporary Redirect"
        RES["HEADERS","Location"]="/"
      fi
    else
      DOM=`render_login_page`
      RES["BODY"]=`render_response "Login" $DOM`
      RES["STATUS"]="200 OK"
    fi

    DOM=`render_login_page ${REQUEST[BODY,username]}`
  elif [[ "${REQUEST[ROUTE]}" == "/logout" ]]; then
    sqlite3 db.sqlite "update sessions set userRowId = NULL where sessId = '${REQUEST[COOKIE,SESSID]}'"
    RES["STATUS"]="307 Temporary Redirect"
    RES["HEADERS","Location"]="/"
  elif [[ "${REQUEST[ROUTE]}" == "/add-new-page" ]]; then
    if [[ "${REQUEST[METHOD]}" == "POST" ]]; then
      IS_IN_MAIN_NAVIGATION="0"
      if [[ "${REQUEST[BODY,is_in_navigation]}" == "1" ]]; then
        IS_IN_MAIN_NAVIGATION="1"
      fi
      sqlite3 db.sqlite "insert into pages values ('${REQUEST[BODY,routepath]}', '${REQUEST[BODY,navtitle]}', ${IS_IN_MAIN_NAVIGATION}, '${REQUEST[BODY,dom]}');" ".exit"
      RES["STATUS"]="307 Temporary Redirect"
      RES["HEADERS","Location"]="${REQUEST[BODY,routepath]}"
    else
      DOM=`render_edit_form`
      RES["BODY"]=`render_response "New page" $DOM`
      RES["STATUS"]="200 OK"
    fi
  elif [[ "${REQUEST[ROUTE]}" == "/edit" ]]; then
    LOGGEDIN_USERID=`sqlite3 db.sqlite "select userRowId from sessions where sessId = '${REQUEST[COOKIE,SESSID]}'" ".exit"`

    if [[ "$LOGGEDIN_USERID" == "" ]]; then
      RES["STATUS"]="403 Forbidden"
      RES["BODY"]=`render_response "Nope" "Not allowed to do that"`
    else
      if [[ "${REQUEST[METHOD]}" == "POST" ]]; then
        IS_IN_MAIN_NAVIGATION="0"
        if [[ "${REQUEST[BODY,is_in_navigation]}" == "1" ]]; then
          IS_IN_MAIN_NAVIGATION="1"
        fi
        sqlite3 db.sqlite "update pages set routePath='${REQUEST[BODY,routepath]}', navTitle='${REQUEST[BODY,navtitle]}', isInMainNavigation=${IS_IN_MAIN_NAVIGATION}, markup='${REQUEST[BODY,dom]}' where routePath='${REQUEST[QUERY,route]}';" ".exit"
        RES["STATUS"]="307 Temporary Redirect"
        RES["HEADERS","Location"]="${REQUEST[BODY,routepath]}"
      else
        PAGE=`sqlite3 db.sqlite "select navTitle, isInMainNavigation, routePath, markup from pages where routePath='${REQUEST[QUERY,route]}'"`
        IFS='|' read -r -d '' -a PAGEPARTS <<< "$PAGE"
        DOM=`render_edit_form ${PAGEPARTS[0]} ${PAGEPARTS[1]} ${PAGEPARTS[2]} ${PAGEPARTS[3]}`
        RES["BODY"]=`render_response "Edit" $DOM`
        RES["STATUS"]="200 OK"
      fi
    fi
  elif [[ "${REQUEST[ROUTE]}" == "/delete" ]]; then
    LOGGEDIN_USERID=`sqlite3 db.sqlite "select userRowId from sessions where sessId = '${REQUEST[COOKIE,SESSID]}'" ".exit"`

    if [[ "$LOGGEDIN_USERID" == "" ]]; then
      RES["STATUS"]="403 Forbidden"
      RES["BODY"]=`render_response "Nope" "Not allowed to do that"`
    else
      sqlite3 db.sqlite "delete from pages where routePath='${REQUEST[QUERY,route]}';" ".exit"
      echo "delete from pages where routePath='${REQUEST[QUERY,route]}';"
      RES["STATUS"]="307 Temporary Redirect"
      RES["HEADERS","Location"]="/"
    fi
  else
    DOM=`sqlite3 db.sqlite "select markup from pages where routePath='${REQUEST[ROUTE]}';" ".exit"`
    LOGGEDIN_USERID=`sqlite3 db.sqlite "select userRowId from sessions where sessId = '${REQUEST[COOKIE,SESSID]}'" ".exit"`

    if [[ "$LOGGEDIN_USERID" != "" ]]; then
      DOM+="<div style='margin-top: 20px;'><a href='/edit?route=${REQUEST[ROUTE]}'>Edit</a> | <a href='/delete?route=${REQUEST[ROUTE]}'>Delete</a></div>"
    fi

    if [[ "$DOM" == "" ]]; then
      RES["BODY"]=`render_response "Not found" "Not found."`
      RES["STATUS"]="404 Not found"
    else
      RES["BODY"]=`render_response "Bash CMS!" $DOM`
      RES["STATUS"]="200 OK"
    fi
  fi
}

And we're good. With 443 lines of code, we've written a basic CMS from scratch in Bash only!

Demo time!

(The gif might take a few seconds to load...)

Q&A time!

Q: Does it perform well?

A: No. Not at all. This script can handle a single request at a time. Even Apache can handle several hundred connections at once.

Q: Should I use this...

A: No. Please, for the love of everything, don't.

Q: Does the font need to be monospaced? That's so 1990s

A: Yes. We're using Bash, so why shouldn't it be monospaced?

Q: Anything else?

A: I use Arch, by the way.

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!

I wrote a book on CSS Grid - Here's how! 📖💡

Pascal Thormeier — Sat, 20 May 2023 16:10:47 +0000

It's been, again, a while since my last post here on DEV. In between posts, I've been rather busy with all kinds of projects. By far the largest of these is a book on CSS Grid. It'll be released soon and you can get a paperback or ebook copy over on Amazon.

Of course, this post is also meant to promote the book a bit, otherwise I wouldn't have posted it in #showdev, but I'd like to focus on the process of how this behemoth of a project came to be in the first place and what it took to get it out there. I also want to inspire people with this post. I want to show you how I worked on this and the necessary steps to complete it. A look behind the curtain, so to speak.

As a little disclaimer: This story is written from memory, but it shows the process nevertheless.

About the book itself

So, what did I actually write about? The title "Mastering CSS Grid" pretty much explains it: CSS Grid. I wrote about the basics and advanced CSS Grid rules, such as grid templates, responsiveness and nested grids.

The book also contains parts about design best practices, grid alternatives, and how CSS Grid and Flexbox play together. A chapter about different frameworks, such as Bootstrap, Tailwind, Tachyons and many more, shows how different popular frameworks understand grids and how they can be used to achieve default use cases, such as the "header-sidebar-content-footer" layout. The last chapter is a comprehensive cheat sheet and quick reference for all of CSS Grid and all related topics discussed in the book.

If you want to order the book as either an ebook or a paperback, if you want to keep it on your desk, you can find it here!

How it started

My writing career started a few years ago on DEV. I first wanted to find a bit of a nieche to write about, but didn't get the traction I originally expected. I then settled on writing about all kinds of things tech, mostly what I'm good at, sometimes learning a lot myself while writing. I wanted to have fun writing, and boy oh boy, do I still have fun doing it. And, in my opinion, that's what it's all about: Having fun, growing and helping others grow, too.

At some point in time, precisely in August 2022, I got lucky. Like, very lucky. I received an email of someone at Packt. They said that they've read my articles and found them "insightful and impressive" and that they were currently looking for authors, specifically for a book about CSS Grid. I would've been foolish to deny that offer.

And so I accepted.

My personal first lesson: Don't try, just do it. I never had the goal to "attract a publisher" and start working on a book. Of course, writing a book was a long-term goal of mine, but my writing on DEV wasn't meant to lead to that. I did what I liked, the rest came around eventually. Of course, a great bit of luck is involved, but writing is a skill one can train, learning in the open is a great thing to do anyways, and once a sufficient skill level and audience is achieved, publishers will notice.

Baby steps

The first step wasn't even the contract. It was an outline. The folks at Packt provided me with a template, describing the target group, a list of chapters, what topics each chapter would cover, what the reader will learn and what benefits they would gave once they've read the chapter. They had a very specific idea of topics in mind and wanted to make sure that the outline would cover all of these at least somehow.

The chapter names and rough section titles for each chapter, of course, were drafts. We wanted to make sure to have at least some idea of what this book will look like in the end.

Afterwards came the organisational part. They proposed a contract, which we both signed. I got introduced to the project manager, the editor, and many more people of the team. These people then introduced me to the tools we would use.

After that, I started writing.

My second learning: Do not underestimate the organisational effort of such a project. There is a reason that book publishing companies are successful and exist since basically the invention of the printing press. These people are experts. They know about steps in the process we non-publishers don't even know we don't know.

Getting sober

And I immediately started writing on the wrong part of the book. I started with the foreword, including it in chapter 1. I thought that, logically, this would be the first part of the book, so it should be written first, right?

Wrong.

The reader should "hit the ground running" with CSS Grid. However, the people at Packt were understanding. They told me to keep the draft for a later stage of the project. So, after the first bit of frustration, I understood their intention: The reader may have already read the foreword and would want to finally learn something.

After I completed the first draft of chapter 1, I eagerly awaited the feedback, expecting a few comments at maximum. But then I opened word and saw dozens of comments. They were devastating at first. Some examples:

"Please elaborate here."
"What do you mean with this?"
"Incomplete sentence, did you mean [...]?"
"Please introduce this figure first, then include the figure, then explain the figure."
"Don't use words such as above or below, as locations may very well be off after editing in the print version."

I sobered up. And I was frustrated. The editor added that they first needed to accustom to my style of writing, but that it was otherwise a very solid start. I can only imagine what a non-solid start would've looked like.

My third learning: Even if there is a lot of critique, it only shows the potential. I started writing the book with a certain mindset and many assumptions about the process. I've never written a book before and deliberately wanted to dive into it head-first. Of course I would first run into a wall. But the publsiher is there to help, dunk on the author. After all, they are as interested in the quality and success of this book as I am, so why should they mean any harm? Of course, the critique is frustrating and demoralizing, but that's the ego talking. It should be seen as an opportunity to grow. Thinking back to my studies, the people proofreading my thesis told me that dozens and dozens of comments are the absolute norm, not a sign that the work is of bad quality. And that's true.

A lot of progress

After sobering up, discussing some concepts (such as how to deal with figures), having a call or two with the team and working further, I got into a flow.

I handed in each chapter individually, as a MS Word document. Word, even though I personally prefer markdown, has the advantage of allowing for comments and very clear visual formatting.

The people at Packt gave me some very sophisticated templates to work with. Bold text would not only be bold, but also magenta, code blocks would be monospaced and have a bright blue as their background colour, callouts and editor notes were in bright signal colours. Even though these formats irritaed me at first, because why would anyone print it this way, I quickly noticed that these tools also help me to gain an overview and that they also helped the layout team to understand how they should format the content.

I had a deadline for each chapter. Once I received the chapter, I had a deadline to incoporate feedback. Once I received the tech reviews, I had fixed deadlines to incoporate their feedback. Once I worked on the final drafts, I had deadlines for incoporate their feedbacks.

Deadlines help. Especially when working on a creative project. I encountered writer's block more than once, but I had to find ways to counteract it, otherwise I would not meet the deadline. The feedback cycles got shorter, the comments got less and less and at some point, we all got into a flow. And progress was made.

My fourth learning: Find ways to get into a flow, embrace the flow and work on maintaining it. You'll get better at writing. Dividing the project into smaller sub-projects helps a lot and deadlines make you keep yourself from overengineering.

The final steps

The tech review was a huge milestone. The folks at Packt found two amazing experts to work on the entire book and give their feedback. They found details that I would've never seen, simply because they were not nearly as deep in this project as I was. The additional pairs of eyes were basically an asynchronous version of duck debugging.

At this point, I want to shout out to
Giuseppe Caruso and Michelle Manemann (ordered alphabetically) for their hard work. Without them, we wouldn't have reached the quality level we have reached in the end.

Given, incorportaing their feedback was hard. I had to restructure many sections, replace many figures and add a ton of stuff, but in the end, it was worth the effort.

The final drafts of all chapters had a total of a dozen comments in the end, we had to replace a few images because the platform refused them (something about illegible text on some screenshots), but the polishing phase did not take much from my end.

And with this, we were done.

My fifth learning: Do not underestimate the help of people that don't know what you've been writing about. Get in a fresh pair of eyes every now and again to help with details. They will find things you would've never noticed.

The aftermath

The book is done. What more is there? Well, as it turns out, a lot: Posts like these, for example.

I asked in my company if people would like a free ebook in exchange for an Amazon review. I still want to polish a thing or two in the official GitHub repository (mainly add some comments, but alas). I want to promote the work myself, get it out to people. There may be a second edition, a third one, fourth or fifth.

My sixth learning: Just because the bulk of the work is done doesn't mean that you'll never hear back from it. I'm constantly checking on my social media posts, tracking how many impressions they got. I check the Amazon best seller ranks to see how it's doing in pre-sales. I can't wait to hold it in my hands. Even though I'm finished, the best is yet to come.

In conclusion

Writing a book is a lot of work. It took me many of my weekends, many of my free afternoons and, sometimes, frustrated me to the point that I just wanted to give up. I invested a lot, and so did the publisher team at Packt. We've all contributed to this.

And this is my seventh learning: Writing a book is not something a single person does. Even though their name is written on the cover. It is a group effort. And I'm forever thankful for having this opportunity. It fulfills a live-long dream.

And please excuse the occasional typo, wrong comma or whatever you may find. I've done my share of editing for a few weeks. :D

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!

Use ALL the Features: How To Create a Fancy Password Input With Vue3 🔑✅

Pascal Thormeier — Sat, 01 Apr 2023 10:50:39 +0000

Vue 3 has brought us a ton of fancy new features. The composition API lets us create components in a more intuitive, JS-y way, there is now support for multiple v-model directives, full TypesSript support out of the box, and the reactivity improved a lot when compared to Vue2.

Today, we'll put these things to use to create a fancy password input component: One that lets us define password requirements and informs the outer component and the user about the password validity and the password.

The basis

First, we create a new Vue component called PasswordInput.vue. In there, we add some template, an amepty script tag and some styling:

<template>
  <div class="password-input">
    <label for="password">
      Enter password
    </label>

    <!-- We'll add stuff to this input later -->
    <input
      type="password"
      id="password"
    >

    <button>
      Show password
    </button>

    <label for="password-repeat">
      Repeat password
    </label>

    <!-- We'll add stuff to this input later -->
    <input
      type="password"
      id="password-repeat"
    >

    <ul class="requirements">
      <!-- Add requirements here -->
    </ul>
  </div>
</template>

<script setup lang="ts">

</script>

<style scoped>
.password-input {
  display: flex;
  flex-direction: column;
}

label {
  margin-bottom: 8px;
  font-size: 16px;
}

input {
  margin-bottom: 12px;
  padding: 8px;
  font-size: 16px;
}

button {
  margin-bottom: 12px;
}

.requirements {
  font-weight: bold;
}

.is-success {
  color: #96CA2D;
}

.is-error {
  color: #BA3637;
}
</style>

We added two input fields for password and password repeat, a button that will show and hide the password as well as an unordered list for the password requirements that we'll add later.

Notice how we're using <script setup lang="ts"> to tell Vue that we want to use the composition API for the entire component.

The styling already includes classes for success and failure. The rest is rather rudimentary. When we use the component, we should see something like this:

Hooking up the fields

Let's add two refs for the password and password repeat. We also add a flag to determine if the password is currently shown or not. While we're at it, we also import computed and watch, because we'll use that later. For that, we add the following to the script tag:

import { computed, ref, watch } from 'vue'

const password = ref('')
const passwordRepeat = ref('')
const showPassword = ref(false)

We can now hook these up with the template:

<!-- ... -->
    <label for="password">
      Enter password
    </label>

    <input
      :type="showPassword ? 'text' : 'password'"
      v-model="password"
      @change="$emit('update:password', $event.target.value)"
      id="password"
    >

    <button @click="showPassword = !showPassword">
      {{ showPassword ? 'Hide password' : 'Show password' }}
    </button>

    <label for="password-repeat">
      Repeat password
    </label>

    <input
      :type="showPassword ? 'text' : 'password'"
      v-model="passwordRepeat"
      id="password-repeat"
    >
<!-- ... -->

Adding the requirements

Now comes the fun part. We want to validate the password with the following requirements:

It should be at least 8 characters long
It should contain at least one uppercase letter
It should contain at least one lowercase letter
It should contain at least one symbol
It should contain at least one number
It must match the "Repeat password" field

To get Vue's reactivity in, we can create a computed value that checks the password ref for all fo these:

const passwordRequirements = computed(() => ([
  {
    name: 'Must contain uppercase letters',
    predicate: password.value.toLowerCase() !== password.value,
  },
  {
    name: 'Must contain lowercase letters',
    predicate: password.value.toUpperCase() !== password.value,
  },
  {
    name: 'Must contain numbers',
    predicate: /\d/.test(password.value),
  },
  {
    name: 'Must contain symbols',
    predicate: /\W/.test(password.value),
  },
  {
    name: 'Must be at least 8 characters long',
    predicate: password.value.length >= 8,
  },
  {
    name: 'Must match',
    predicate: password.value === passwordRepeat.value,
  }
]))

Using an array of requirements has several advantages:

We can extend it whenever we like
Rendering it is trivial with a v-for loop
We can reuse the predicates and move them to a utils file or use them in a state management system

Let's render the requirements in the list:

<!-- ... -->
    <ul class="requirements">
      <li
        v-for="(requirement, key) in passwordRequirements"
        :key="key"
        :class="requirement.predicate ? 'is-success' : 'is-error'"
      >
        {{ requirement.name }}
      </li>
    </ul>
<!-- ... -->

Now, whenever the user changes either one of the values, the requirements are recalculated and updated in the template, giving feedback to the user directly. We should now see something like this:

So far so good!

Emitting changes and usage

We now want to make the component usable. For that, we need to emit changes. Since Vue now allows to have multiple v-model directives on a component, we can emit different events in case of changes to either password field. For that, we add @change event listeners to the password input fields:

<!-- ... -->
    <input
      :type="showPassword ? 'text' : 'password'"
      v-model="password"
      @change="$emit('update:password', $event.target.value)"
      id="password"
    >

<!-- ... -->

    <input
      :type="showPassword ? 'text' : 'password'"
      v-model="passwordRepeat"
      @change="$emit('update:passwordRepeat', $event.target.value)"
      id="password-repeat"
    >
<!-- ... -->

We then also want to emit if the password is valid or not, so a single boolean value. We use a watch for that, that will watch the passwordRequirements compured value and emit a single boolean.

const emit = defineEmits([
  'update:password',
  'update:passwordRepeat',
  'update:validity'
])

watch(passwordRequirements, () => {
  emit(
    'update:validity',
    passwordRequirements.value.reduce((v, p) => v && p.predicate, true)
  )
})

And done! The component now emits changes for the password, the password-repeat field, and the password validity. It also shows the user direct visual feedback about the password's validity and let's them show or hide the password to see if they perhaps mistyped.

We can now use the component as follows in any template:

<template>
  <!-- ... -->
  <PasswordInput
    v-model:password="password"
    v-model:password-repeat="passwordRepeat"
    v-model:validity="isPasswordValid"
  />
  <!-- ... -->
</template>

Awesome!

💡 Want to learn more about Vue and its advanced features? I recently published a course on Educative.io called "Advanced VueJS: Build Better Applications Efficiently"!

In 51 lessons, you can learn about all kinds of features, such as custom events, advanced templating, how to use APIs, I18n or slots and hooks.

You can find the course over on Educative.io!

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!

I asked ChatGPT to draft a four-hour agile retrospective - here's how it went 🦾💬

Pascal Thormeier — Wed, 01 Feb 2023 21:00:00 +0000

Last weekend, I had the task to craft and hold a four-hour workshop for a group of people who have been working together for years. The group faced a few problems lately: Since they started working on their shared project in their spare time, motivation has decreased, and so has productivity. At some point, there wasn't any progress in months.

They wanted to identify the main problems and find solutions for them. They were very well aware that they needed to discuss a lot and take their time, hence the four-hour timeframe.

I hadn't held such a workshop in ages and was running out of time to prepare it, so I asked ChatGPT for help. We've seen ChatGPT code a lot now. Let's see if it can also act as an agile coach.

The prompt

On LinkedIn, I've seen many guides on using ChatGPT. Most of them focus on how to pose questions, but one interesting detail that keeps popping up is how people tell the AI to "pretend" to be someone else that would be very knowledgeable on the requested topic.

Grant "3blue1brown" Sanderson has shown us on Twitter what could be done with that technique:

// Detect dark theme var iframe = document.getElementById('tweet-1600565043602477056-742'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1600565043602477056&theme=dark" }

So I tried the same. I asked ChatGPT to pretend to be a business consultant with focused experience in process optimization and agile methods.

Pretend you're an expert business consultant specializing in processes and Agile development methods.

Then I described the problem as detailed as I could and asked for a concept of a four-hour workshop:

The company you're consulting has an issue. It's a team of five people that were very motivated initially and had many ideas for bringing the company forward. They had worked hard on all their tasks and achieved a lot initially. However, since the company is a side project for all of them, they all lost motivation and started to work less and less on the actual tasks, always finding excuses. People seem demotivated now and are thinking about closing the company, even though they don't want to. They try to have regular stand-up meetings and update each other on the tasks, but often they don't have any updates. They used some agile process, which resembles Kanban. Please generate the concept for a four-hour workshop aiming at finding the reasons for the issues mentioned and finding solutions.

I used the term "company", although it's a loose group of friends working on the same project. I thought that ChatGPT could, in this particular setting, work best with a company since it pretended to be a business consultant.

Surprisingly, the concept was coherent and aimed at finding problems and generating solutions.

The workshop concept

So, ChatGPT described a workshop in six steps, essentially describing a SCRUM retrospective.

Here is a concept for a four-hour workshop that aims to address the issues you described:

Introduction: Begin the workshop by setting the context and explaining the purpose of the session. Let the team know that the goal is to identify the reasons for their demotivation and find solutions to get back on track.

Identifying the issues: In this step, the team will work together to identify the specific problems causing demotivation and decreased productivity. This can be done through a group discussion, individual brainstorming, or a combination of both. Encourage open and honest communication during this step.

Root cause analysis: Once the issues have been identified, the next step is to understand why these issues are occurring. This can be done through a technique such as "5 Whys" where the team asks "why" a specific problem is occurring, and then asks "why" again for each answer until the root cause is identified.

Brainstorming solutions: Once the root causes have been identified, the team can brainstorm potential solutions to address these issues. Encourage the team to think outside the box and consider all options.

Prioritizing and action planning: After the solutions have been identified, the team can prioritize which solutions to implement first. Then, they can create an action plan to put these solutions into practice.

Closing: Close the workshop by summarizing what was discussed, identifying next steps, and setting up a follow-up meeting to track progress and make adjustments as needed.

Throughout the workshop, it is important to focus on creating a positive and supportive environment, where everyone feels heard and respected. Encourage open communication, active participation, and a willingness to take ownership and make changes.

Although ChatGPT apparently does have some "expertise" with these topics, it does help to know agile setups and perhaps even have experience with moderating workshops in general.

I dug deeper.

That's already a strong basis. How can they set the context better in the beginning? Please generate a light and fun starting exercise for the first step.

And ChatGPT delivered.

Here's a similar exercise that can work well for small groups of 4 participants:

"Motivation Web": Create a large web on a whiteboard or flipchart, with a central circle labeled "Motivation" and lines radiating out to different circles labeled with various factors that can impact motivation such as "Workload", "Communication", "Recognition", "Purpose", "Autonomy", "Support", etc.

Give each participant a set of sticky notes, and ask them to write down their current thoughts and feelings on their motivation levels and how they relate to the different factors on the web.

Once they have written their notes, ask them to place their notes on the appropriate circles of the web.

After everyone has placed their notes, ask the group to come back together and have a discussion about the web. This will help to create a sense of connection and understanding among the team, and also give you an idea of the team's current motivation levels and which factors are impacting it.

This can be a great way to start the workshop, as it helps to set the context by identifying the team's current motivation levels and the factors that are impacting it, and provides a platform for open and honest communication.

You can use this exercise as an introduction to the workshop, and move on to the next steps of identifying the issues, root cause analysis, brainstorming solutions, and action planning.

This exercise is also light and fun, and should not take more than 15 minutes, it's meant to be a warm up that will help the team to relax and get ready for the rest of the workshop.

And this really surprised me. I didn't find any other resources on the "Motivation web" activity. So, either it found some obscure unknown method, or it came up with the activity itself, essentially showing creative skills.

The former seems more likely, though.

I asked a few more questions to elaborate on some of the activities, especially on the issue identification and the solution finding.

One of the main issues, though, was that it kept suggesting activities for large groups and had to constantly be reminded that there would only be four to five people present.

Holding the workshop

I mostly stuck to the script: Starting with an exercise I came up with myself, continuing with the motivation web, and then going through the issue hunt and the "five whys" activity.

It went surprisingly well. Although I had to improvise here and there, the timeframes it suggested were quite precise, and we ended up having identified some core issues and solutions for them.

However, from here on, it's our job to stick to these solutions and implement them.

I did tell the participants that I had a helping hand preparing the workshop and only told them afterwards that it was ChatGPT. Their surprised faces were priceless. Although, some felt that I was, in a way, cheating.

Conclusion

Can ChatGPT replace an agile coach? Certainly not. It lacks the emotional intelligence that is necessary to react to conflicts.

Since the chatbot is a passive entity, it can only react unless we constantly feed it with data from the daily standups and other SCRUM rituals.

Can ChatGPT support junior agile coaches, though? It darn well can! Asking for workshop concepts that are tailored to situations is a feat ChatGPT can do very well.

Generally speaking, the AI can cut the time necessary for workshop preparation a lot, giving agile coaches more opportunity to focus on other tasks.

In conclusion, I would ask it again. I would, however, take the suggestions with a grain of salt and improvise where necessary. ChatGPT can replace the initial thinking steps, but it cannot replace knowledge and experience.

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!

Throwing Around Text – Kinetic Typography Part 4: Rotating Around the World 🎡🌍

Pascal Thormeier — Wed, 25 Jan 2023 15:00:00 +0000

Part 4 of my series about kinetic typography! Let's move some text around with HTML, CSS and JS! If you missed how I came about throwing around text and deforming it with only web stuff, be sure to check out part 1, part 2 and part 3!

Finally, I've gotten around to writing again. It has been a busy year for me (both 2022 and even 2023 so far), and you can expect some news about what exactly I was busy with not too far in the future!

Today, though, we're going to throw around some more text. Specifically, we're going to rotate text and make it look like a wheel.

☕ But first, I'd like to shout out to @jamjuniper for supporting me on buymeacoffee! Not only were they really generous (they not only gifted me a coffee, but basically a sandwich with that, too!), but they also became my first-ever member on buymeacoffee! Thank you very much for the support!

The inspiration

I found this specific example in a post about kinetic typography on webdew.com.

What struck me about this is the illusion of a wheel rolling towards the user but built with words. The word "workflow" itself even gives this some philosophical aspect. But we're not here to reflect on our lives; we're here to code.

Let's rebuild this!

Getting the DOM ready

So, to show the same text over and over, we need - well - the same text over and over. To get a good effect, around 21 copies should do.

Coincidentally, the example we're about to build doubles as a visual representation of the lyrics of a famous song by a French electro duo. You can probably guess which one I mean.

<!DOCTYPE html>
<html>
<head>
  <style>
    /* CSS goes here */
  </style>
</head>
<body>
  <div class="wheel">
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
    <div class="line"><p>Around the world</p></div>
  </div>
</body>
</html>

And that's it for the DOM.

Styling the basics

First of all, we want the entire thing to be centred. For that, we size the body to fill the viewport, make it a flexbox and justify its content to the centre.

html, body {
  padding: 0;
  margin: 0;
}

body {
  display: flex;
  height: 100vh;
  align-items: center;
}

Next, we take care of the text styling.

.line p {
  line-height: 0.8;
  padding: 0;
  margin: 0;
  font-family: monospace;
  text-transform: uppercase;
  font-size: 3rem;
  font-weight: bold;
  letter-spacing: 0.75rem;
  white-space: nowrap;
  text-align: center;
}

We then give the .wheel element a height and make it fill the entire width, so the text is centred, too.

.wheel {
  width: 100%;
  height: calc(30rem * 0.8);
}

What we get is this:

Well, this looks like some rendering error, but bear with me!

Adding the animation

Let's analyze how we can animate the text to look like it's attached to a rotating wheel.

First, there is the actual rotation on the X-axis. The text is tilted back 90 degrees when on the top of the wheel and rotates to be tilted forwards by 90 degrees once it arrives at the bottom. The rotation is linear since the "wheel" has a constant speed.

Second, we have the movement. We need to move the text from the top to the bottom of the wheel, hence the height of the .wheel div. Ideally, this would follow some bezier curve (the ease-in-out, to be precise) because of perspective.

Third, we need scaling. In the example, the text at the top and bottom is slightly narrower than the text in the centre. To get the wheel effect, the sizes should describe some curve to give the illusion of a cylinder. So, this animation, too, should follow the same bezier curve.

To animate all of these, we use keyframes. We create three definitions, so we can apply them individually:

@keyframes rotate {
  0% {
    opacity: 1;
    transform: rotateX(90deg);
  }

  50% {
    transform: rotateX(0);
  }

  100% {
    opacity: 1;
    transform: rotateX(-90deg);
  }
}

@keyframes scaleToCenter {
  0% {
    transform: scale(0.9);
  }

  50% {
    transform: scale(1.0);
  }

  100% {
    transform: scale(0.9);
  }
}

@keyframes moveDown {
  0% {
    top: 0;
  }
  100% {
    top: 30rem;
  }
}

So far, so good. Now, we add the keyframes to the elements. Next, we move and scale the .line div and rotate the p element inside it. This way, we can have two values for transform animated with different transition timing functions. We also position the wheel relatively and the lines absolutely so we can use top.

.wheel {
  position: relative;
}

.line {
  width: 100%;
  animation:
    3s infinite forwards ease-in-out scaleToCenter,
    3s infinite forwards ease-in-out moveDown
  ;
  position: absolute;
}

.line p {
  opacity: 0;
  backface-visibility: hidden;
  animation: 3s infinite forwards linear rotate;
}

Now, of course, all the lines will animate simultaneously. We need to add some animation delay to each of them. Although a bit tedious, we can now really fine-tune the timing to get a nice wheel-shaped wall of text:

.line:nth-child(2), .line:nth-child(2) p { animation-delay: 0.15s }
.line:nth-child(3), .line:nth-child(3) p { animation-delay: 0.3s }
.line:nth-child(4), .line:nth-child(4) p { animation-delay: 0.45s }
.line:nth-child(5), .line:nth-child(5) p { animation-delay: 0.6s }
.line:nth-child(6), .line:nth-child(6) p { animation-delay: 0.75s }
.line:nth-child(7), .line:nth-child(7) p { animation-delay: 0.9s }
/* You get the idea... */

We also use the CSS perspective property to really get the wheel effect. This property lets us specify how far away the user is from the Z plane of the web application. When we transform an element in 3D space, CSS will calculate what this would look like, depending on the angle.

.line {
  perspective: 150rem;
  perspective-origin: center;
}

And we're done already! Awesome!

The result

You spin me right round, baby, right round!

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!

dev.to codes! Collaborative coding experiment: The most liked comment picks the next line of code, day 5

Pascal Thormeier — Sat, 12 Nov 2022 20:52:21 +0000

Welcome to day 5! I think we're passt the next "line" of code, so we'll use the most liked "piece" of code from here on. Not an issue, though. Congrats to @rafaelhashimoto for picking this large snippet. I had to adjust it a bit to fit the previous code.

his experiment is inspired by a post on the ProgrammerHumor subreddit, where the original author did this exact thing: The most liked comment after 24 hours picks the next line of code.

The rules:

Nothing that's against any applicable law
Nothing that's against the community code of conduct, terms of use, or privacy policy
No leaking of personal information of anyone
No malware/ransomware/viruses/etc.
Keep it civil
(To be expanded, depending on the case)

Our code so far:

emotions = ["🥲", "🥰", "🥺", "😫", "🤬", "😞", "😅", "😊", "😰"]
how_i_feel_right_now = emotions.sample
if how_i_feel_right_now === "😊"
    letsDoThis()
end
def letsDoThis
  # things a person can do that will change his humor
  what_have_i_done = "🥲" if big_mistakes
  how_i_feel_right_now =  what_have_i_done
end

def big_mistakes
  deploy_on_friday() || buy_twitter()
end

def buy_twitter
  raise AquisitionError, "I won't buy it" if user_base_has_bots?
rescue AquisitionError => e
   puts e.message
   true # because you can't step back
end

def user_base_has_bots?
  true # well... yes
end

(I had to adjust the code a bit for it to be valid Ruby.)

See you in 24 hours!