diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..137ffbf --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +zig-cache +*.tgz diff --git a/README.md b/README.md index e34cd80..ad0d645 100644 --- a/README.md +++ b/README.md @@ -2,5 +2,5 @@ ## Build Instructions -This homepage uses [VSS](https://github.com/vssio/vss/). To build, use: -`vss build` or `vss serve`. +This homepage uses [zine](https://zine-ssg.io/). To build, use: +`zig build` or `zig build serve -Dport=8080`. diff --git a/bin/blog.ts b/bin/blog.ts deleted file mode 100644 index d4fdbb5..0000000 --- a/bin/blog.ts +++ /dev/null @@ -1,97 +0,0 @@ -#!/bin/env deno run - -import { globber } from "https://deno.land/x/globber@0.1.0/mod.ts" - -interface FileIndex { - title: string - slug: string - abstr: string - date: string - readingTimeSlow: number - readingTimeFast: number -} - -const cwd = './blog/' -const outputPath = './blog/index.md' - -const fileIndex: FileIndex[] = [] - -const fileIter = globber({ cwd, include: ["????-??-??*.md"] }) -const decoder = new TextDecoder('utf-8') -const encoder = new TextEncoder() - -const header = `*Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.* - -Last updated: ${(new Date()).toISOString().slice(0,10)} - -` - -const template = `
- -
- %TITLE% - (%READING_TIME_FAST% to %READING_TIME_SLOW% minutes) -
-

- %ABSTRACT% -

-
-` - -function getAbstract(lines: string[]): string { - const sep = '' - const sep2 = '' - let foundSep = false - - return lines.slice(3).filter(line => { - if (foundSep) return false - if (line.indexOf(sep) >= 0 || line.indexOf(sep2) >= 0) { - foundSep = true - return false - } - return true - }).join('\n').trim() -} - -function render(fi: FileIndex) { - return template - .replaceAll('%DATE%', fi.date) - .replaceAll('%TITLE%', fi.title) - .replaceAll('%SLUG%', fi.slug) - .replaceAll('%ABSTRACT%', fi.abstr) - .replaceAll('%READING_TIME_FAST%', fi.readingTimeFast) - .replaceAll('%READING_TIME_SLOW%', fi.readingTimeSlow) -} - -for await (const file of fileIter) { - if (file.isDirectory) { - console.log('ignoring directory', file.relative) - break - } - - const path = file.absolute - const date = file.relative.slice(0, 10) - const slug = file.relative.slice(0, -3) - - const raw = await Deno.readFile(path) - const text = decoder.decode(raw) - const words = text.trim().split(/\s+/).length - const lines = text.split('\n') - - const title = lines[0].slice(2) - const abstr = getAbstract(lines) - - // calculates estimated reading times: [fast, slow] - // wpm numbers from https://thereadtime.com/ - const readingTimeFast = Math.round(words / 207) - const readingTimeSlow = Math.round(words / 167) - - fileIndex.push({ title, slug, abstr, date, readingTimeFast, readingTimeSlow }) -} - -const output = fileIndex -.sort((a, b) => a.date.localeCompare(b.date) * -1) -.map(render) -.join('\n') - -Deno.writeFile(outputPath, encoder.encode(header+output)) diff --git a/bin/til.ts b/bin/til.ts deleted file mode 100644 index 2cc4b78..0000000 --- a/bin/til.ts +++ /dev/null @@ -1,65 +0,0 @@ -#!/bin/env deno run - -import { globber } from "https://deno.land/x/globber@0.1.0/mod.ts" - -interface FileIndex { - title: string - source: string - date: string -} - -const cwd = './til/' -const outputPath = './til/index.md' - -const fileIndex: FileIndex[] = [] - -const fileIter = globber({ cwd, include: ["????-??-??.md"] }) -const decoder = new TextDecoder('utf-8') -const encoder = new TextEncoder() - -const header = `*This page contains short notes and sometimes code snippets, of interesting things I just found out.* - -Last updated: ${(new Date()).toISOString().slice(0,10)} - -` - -const template = `
- -
- %TITLE% - (source) -
-
-` - -function render(fi: FileIndex) { - return template - .replaceAll('%DATE%', fi.date) - .replaceAll('%SOURCE%', fi.source) - .replaceAll('%TITLE%', fi.title) -} - -for await (const file of fileIter) { - if (file.isDirectory) { - console.log('ignoring directory', file.relative) - break - } - - const path = file.absolute - const date = file.relative.slice(0, -3) - - const raw = await Deno.readFile(path) - const lines = decoder.decode(raw).split('\n') - - const title = lines[0].slice(2) - const source = lines[2].startsWith('[source](') ? lines[2].slice(9, -1) : '#' - - fileIndex.push({ title, source, date }) -} - -const output = fileIndex -.sort((a, b) => a.date.localeCompare(b.date) * -1) -.map(render) -.join('\n') - -Deno.writeFile(outputPath, encoder.encode(header+output)) diff --git a/bin/vss b/bin/vss deleted file mode 100755 index 225b79e..0000000 Binary files a/bin/vss and /dev/null differ diff --git a/blog/index.md b/blog/index.md deleted file mode 100644 index 99734f3..0000000 --- a/blog/index.md +++ /dev/null @@ -1,83 +0,0 @@ -*Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.* - -Last updated: 2024-05-13 - -
- -
- A store implementation from scratch using Vue3's Composition API - (6 to 8 minutes) -
-

- I've built a store implementation that allows name-spaced actions and helps with the separation of concerns. The new Composition API in Vue3 also allows completely new, convenient ways of using it. -

-
- -
- -
- Freddy vs JSON: how to make a top-down shooter - (25 to 31 minutes) -
-

- I will tell you how I created a simple top-down shooter in JavaScript without using any additional libraries. But this article is not replicating the full game but instead tries to show which steps to take to start writing a game from scratch. -

-
- -
- -
- Use OpenBSDs Spleen bitmap font in Linux - (2 to 2 minutes) -
-

- Yesterday Frederic Cambus changed the default console font in OpenBSD to his self made font [Spleen](https://github.com/fcambus/spleen) as written in this [BSD Journal article](https://undeadly.org/cgi?action=article;sid=20190110064857). -

-
- -
- -
- Running writefreely 0.7 on Arm - (4 to 5 minutes) -
-

- This is a follow-up on -[The expected tutorial: How to install WriteFreely on a Raspberry pi 3 in 10 steps](https://write.as/buttpicker/the-expected-tutorial-how-to-install-writefreely-on-a-raspberry-pi-3-in-10). I will explain what was necessary to make cross-compiling work for newer WriteFreely versions with SQLite support. -

-
- -
- -
- Vuejs Reactivity From Scratch - (8 to 9 minutes) -
-

- Vuejs is the star newcomer in the Javascript Framework world. People love how it makes complicated things very simple yet performant. One of the more exciting features is its seemingly magic reactivity. Plain data objects in components magically invoke a rerender when a property changes. -

-
- -
- -
- The Magic 0xC2 - (3 to 4 minutes) -
-

- I built a web application with file upload functionality. Some Vue.js in the front and a CouchDB in the back. Everything should be pretty simple and straigt forward. - -But… -

-
- -
- -
- The price to crack your password - (6 to 7 minutes) -
-

- Nearly six years ago, I wrote about password complexity and showed how long it takes to crack passwords per length. You can find that [article on github](https://github.com/nkoehring/hexo-blog/blob/master/source/_posts/spas-mit-passwortern.md) (in German). -

-
diff --git a/build.sh b/build.sh deleted file mode 100755 index cffc730..0000000 --- a/build.sh +++ /dev/null @@ -1,3 +0,0 @@ -deno run --allow-read --allow-write bin/til.ts && -deno run --allow-read --allow-write bin/blog.ts && -./bin/vss build diff --git a/build.zig b/build.zig new file mode 100644 index 0000000..f07cab7 --- /dev/null +++ b/build.zig @@ -0,0 +1,12 @@ +const std = @import("std"); +const zine = @import("zine"); + +pub fn build(b: *std.Build) !void { + try zine.addWebsite(b, .{ + .title = "the codeartist — programmer and engineer based in Berlin", + .host_url = "https://koehr.ing", + .layouts_dir_path = "layouts", + .content_dir_path = "content", + .static_dir_path = "static", + }); +} diff --git a/build.zig.zon b/build.zig.zon new file mode 100644 index 0000000..f27c1fe --- /dev/null +++ b/build.zig.zon @@ -0,0 +1,11 @@ +.{ + .name = "koehr.ing", + .version = "0.0.0", + .dependencies = .{ + .zine = .{ + .url = "git+https://github.com/kristoff-it/zine#c4924570fa54ab204bb8b1bf1a140d0cc04ab08a", + .hash = "1220e2050b5fb6788675c0af6b2bfb601226fc90fb32aeeccc95cf9f4945543bd13a", + }, + }, + .paths = .{"."}, +} diff --git a/blog/2016-12-04-the-price-to-crack-your-password.md b/content/blog/2016-12-04-the-price-to-crack-your-password.md similarity index 94% rename from blog/2016-12-04-the-price-to-crack-your-password.md rename to content/blog/2016-12-04-the-price-to-crack-your-password.md index c381a1a..1911d59 100644 --- a/blog/2016-12-04-the-price-to-crack-your-password.md +++ b/content/blog/2016-12-04-the-price-to-crack-your-password.md @@ -1,10 +1,15 @@ -# The price to crack your password - -*Written 2016-12-04* - -Nearly six years ago, I wrote about password complexity and showed how long it takes to crack passwords per length. You can find that [article on github](https://github.com/nkoehring/hexo-blog/blob/master/source/_posts/spas-mit-passwortern.md) (in German). - - +--- +{ +.title = "The price to crack your password", +.date = @date("2016-12-04T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "Nearly six years ago, I wrote about password complexity and showed how long it takes to crack passwords per length.", +.tags = [], +} +--- +You can find the original [article on github](https://github.com/nkoehring/hexo-blog/blob/master/source/_posts/spas-mit-passwortern.md) (in German). So, times changed and I thought about a reiteration of that topic, but instead focussing on the amount of money you need to crack the password using Amazons biggest GPU computing instances [p2.16xlarge](https://aws.amazon.com/ec2/instance-types/), which – at the time of writing this - costs 14.4 USD per hour. I will also compare this with the much faster [Sagitta Brutalis](https://sagitta.pw/hardware/gpu-compute-nodes/brutalis/) (nice name, eh?), a 18500 USD computer optimised for GPU calculation. diff --git a/blog/2017-04-09-the-magic-0xc2.md b/content/blog/2017-04-09-the-magic-0xc2.md similarity index 90% rename from blog/2017-04-09-the-magic-0xc2.md rename to content/blog/2017-04-09-the-magic-0xc2.md index ffc51e0..7495090 100644 --- a/blog/2017-04-09-the-magic-0xc2.md +++ b/content/blog/2017-04-09-the-magic-0xc2.md @@ -1,13 +1,14 @@ -# The Magic 0xC2 - -*Written 2017-04-09* - -I built a web application with file upload functionality. Some Vue.js in the front and a CouchDB in the back. Everything should be pretty simple and straigt forward. - -But… - - - +--- +{ +.title = "The Magic 0xC2", +.date = @date("2017-04-09T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "I built a web application with file upload functionality. Some Vue.js in the front and a CouchDB in the back. Everything should be pretty simple and straigt forward. But…", +.tags = [], +} +--- When I uploaded image files, they somehow got mangled. The uploaded file was bigger than the original and the new "file format" was not readable by any means. I got intrigued. What is it, that happens to the files? The changes seemed very random but reproducible, so I created a few test files to see what exactly changes and when. My first file looked like this: diff --git a/blog/2017-08-17-vuejs-reactivity-from-scratch.md b/content/blog/2017-08-17-vuejs-reactivity-from-scratch.md similarity index 96% rename from blog/2017-08-17-vuejs-reactivity-from-scratch.md rename to content/blog/2017-08-17-vuejs-reactivity-from-scratch.md index 1d1a67d..b575477 100644 --- a/blog/2017-08-17-vuejs-reactivity-from-scratch.md +++ b/content/blog/2017-08-17-vuejs-reactivity-from-scratch.md @@ -1,11 +1,14 @@ -# Vuejs Reactivity From Scratch - -*Written 2017-08-17* - -Vuejs is the star newcomer in the Javascript Framework world. People love how it makes complicated things very simple yet performant. One of the more exciting features is its seemingly magic reactivity. Plain data objects in components magically invoke a rerender when a property changes. - - - +--- +{ +.title = "Vuejs Reactivity From Scratch", +.date = @date("2017-08-17T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "Vuejs is the star newcomer in the Javascript Framework world. People love how it makes complicated things very simple yet performant. One of the more exciting features is its seemingly magic reactivity. Plain data objects in components magically invoke a rerender when a property changes.", +.tags = [], +} +--- _NOTE_: This is a copy of the original article from Aug 17th, 2017. You can [read the archived original on archive.org](https://web.archive.org/web/20190113013559/https://log.koehr.in/2017/08/17/vuejs-reactivity-from-scratch) diff --git a/blog/2019-01-10-running-write-freely-on-arm.md b/content/blog/2019-01-10-running-write-freely-on-arm.md similarity index 94% rename from blog/2019-01-10-running-write-freely-on-arm.md rename to content/blog/2019-01-10-running-write-freely-on-arm.md index 48a7007..578a2da 100644 --- a/blog/2019-01-10-running-write-freely-on-arm.md +++ b/content/blog/2019-01-10-running-write-freely-on-arm.md @@ -1,11 +1,21 @@ -# Running writefreely 0.7 on Arm +--- +{ +.title = "Running writefreely 0.7 on Arm", +.date = @date("2019-01-10T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "What was necessary to make cross-compiling work for newer WriteFreely versions with SQLite support.", +.tags = [], +} +--- -*Written 2019-01-10* +--- This is a follow-up on -[The expected tutorial: How to install WriteFreely on a Raspberry pi 3 in 10 steps](https://write.as/buttpicker/the-expected-tutorial-how-to-install-writefreely-on-a-raspberry-pi-3-in-10). I will explain what was necessary to make cross-compiling work for newer WriteFreely versions with SQLite support. +[The expected tutorial: How to install WriteFreely on a Raspberry pi 3 in 10 steps](https://write.as/buttpicker/the-expected-tutorial-how-to-install-writefreely-on-a-raspberry-pi-3-in-10). - +--- I did it! I finally got WriteFreely to run on my Arm server (check out [Scaleways baremetal cloud servers](https://www.scaleway.com/baremetal-cloud-servers/)). diff --git a/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md b/content/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md similarity index 81% rename from blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md rename to content/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md index 6c9fe7f..950cb32 100644 --- a/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md +++ b/content/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md @@ -1,10 +1,15 @@ -# Use OpenBSDs Spleen bitmap font in Linux - -*Written 2019-01-10* - -Yesterday Frederic Cambus changed the default console font in OpenBSD to his self made font [Spleen](https://github.com/fcambus/spleen) as written in this [BSD Journal article](https://undeadly.org/cgi?action=article;sid=20190110064857). - - +--- +{ +.title = "Use OpenBSDs Spleen bitmap font in Linux", +.date = @date("2019-01-10T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "Yesterday Frederic Cambus changed the default console font in OpenBSD to his self made font.", +.tags = [], +} +--- +The font is called [Spleen](https://github.com/fcambus/spleen), as mentioned in this [BSD Journal article](https://undeadly.org/cgi?action=article;sid=20190110064857). To be totally honest, I stopped thinking about TTY (aka console) fonts a long time ago. It just happened to get interesting again when I got a HiRes screen and suddenly a magnifying glass was necessary to read the TTY. Yes I am one of those people who still deny the existence of graphical installers. If you want to change my mind, feel free to write me. diff --git a/blog/2019-05-03-freddy-vs-json.md b/content/blog/2019-05-03-freddy-vs-json.md similarity index 98% rename from blog/2019-05-03-freddy-vs-json.md rename to content/blog/2019-05-03-freddy-vs-json.md index 4415112..3a0e466 100644 --- a/blog/2019-05-03-freddy-vs-json.md +++ b/content/blog/2019-05-03-freddy-vs-json.md @@ -1,11 +1,14 @@ -# Freddy vs JSON: how to make a top-down shooter - -*Written 2019-05-03* - -I will tell you how I created a simple top-down shooter in JavaScript without using any additional libraries. But this article is not replicating the full game but instead tries to show which steps to take to start writing a game from scratch. - - - +--- +{ +.title = "Freddy vs JSON: how to make a top-down shooter", +.date = @date("2019-05-03T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "I will tell you how I created a simple top-down shooter in JavaScript without using any additional libraries. But this article is not replicating the full game but instead tries to show which steps to take to start writing a game from scratch.", +.tags = [], +} +--- A couple of years ago (Oh it's almost a decade! Am I that old already?), when the Canvas API got widely adopted by most browsers, I started experimenting with it. The fascination was high and I immediately tried to use it for interactive toys and games. Of course, the games I made (and make) are usually not very sophisticated. That is mainly because I create them only for fun and without much eye-candy or even sound. What really fascinates me is the underlying mechanics. Otherwise, I could just use one of those [awesome game engines](https://github.com/collections/javascript-game-engines), that exist already. diff --git a/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md b/content/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md similarity index 95% rename from blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md rename to content/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md index b0efa21..152d9bc 100644 --- a/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md +++ b/content/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md @@ -1,10 +1,14 @@ -# A store implementation from scratch using Vue3's Composition API - -*Written 2020-06-29* - -I've built a store implementation that allows name-spaced actions and helps with the separation of concerns. The new Composition API in Vue3 also allows completely new, convenient ways of using it. - - +--- +{ +.title = "A store implementation from scratch using Vue3's Composition API", +.date = @date("2020-06-29T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "I've built a store implementation that allows name-spaced actions and helps with the separation of concerns. The new Composition API in Vue3 also allows completely new, convenient ways of using it.", +.tags = [], +} +--- --- diff --git a/content/blog/index.md b/content/blog/index.md new file mode 100644 index 0000000..64d4c57 --- /dev/null +++ b/content/blog/index.md @@ -0,0 +1,13 @@ +--- +{ +.title = "Blog", +.date = @date("2024-05-13T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "blog.html", +.description = "Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.", +.tags = [], +} +--- + + diff --git a/cv/index.md b/content/cv.md similarity index 93% rename from cv/index.md rename to content/cv.md index 18b6228..cd17f00 100644 --- a/cv/index.md +++ b/content/cv.md @@ -1,7 +1,14 @@ -*My Curriculum Vitae / Resume. I know, there is a difference. This page is technically a resume, while the whole site would be closer to a CV.* - -Last updated: 2024-05-20 - +--- +{ +.title = "CV / Résumé", +.date = @date("2024-05-20T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "My Curriculum Vitae / Résumé. I know, there is a difference. This page is technically a résumé, while the whole site would be closer to a CV.", +.tags = [], +} +--- In me you will find an enthusiastic, passionate developer with around 13 years of professional experience in and around software development, mainly full-stack web development and consulting, but also coaching and community work. I strive to seek roles in creative, forward thinking companies with diverse teams that offer challenging work, trust and responsibility. Since 2022 I'm the principal frontend engineer and frontend chapter lead of [Code Gaia](https://codegaia.io). diff --git a/index.md b/content/index.md similarity index 59% rename from index.md rename to content/index.md index eafd8a6..da68384 100644 --- a/index.md +++ b/content/index.md @@ -1,3 +1,14 @@ +--- +{ +.title = "Welcome", +.date = @date("2024-06-16T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "homepage.html", +.description = "", +.tags = [], +} +--- # experience > Thirteen years of professional experience in a couple of tweets @@ -24,22 +35,22 @@ Many people want to learn and grow. Whenever I can I try to help those people by
- ![Mail](/mail.svg) n@<this domain> + n@[thisdomain] - ![Fediverse / Mastodon](/fediverse.svg) [@Koehr\@mstdn.io](https://mstdn.io/@Koehr/) + [@Koehr\@mstdn.io](https://mstdn.io/@Koehr/) - ![Gitforge](/gitforge.svg) [git.k0r.in](https://git.k0r.in/) + [git.k0r.in](https://git.k0r.in/) - ![LinkedIn](/linkedin.svg) [Norman Köhring](https://linkedin.com/in/norman-köhring-950448109/) + [Norman Köhring](https://linkedin.com/in/norman-köhring-950448109/) - ![Instagram](/instagram.svg) [coffee_n_code](https://instagram.com/coffee_n_code/) + [coffee_n_code](https://instagram.com/coffee_n_code/) - ![Threads](/threads.svg) [coffee_n_code](https://instagram.com/coffee_n_code/) + [coffee_n_code](https://threads.net/@coffee_n_code/) - ![Reddit](/reddit.svg) [/u/koehr](https://www.reddit.com/user/koehr/) + [/u/koehr](https://www.reddit.com/user/koehr/) - ![Github](/github.svg) [nkoehring](https://github.com/nkoehring/) + [nkoehring](https://github.com/nkoehring/) - ![Twitter](/twitter.svg) [koehr_in](https://twitter.com/koehr_in/) + [koehr_in](https://twitter.com/koehr_in/)
diff --git a/now/index.md b/content/now.md similarity index 65% rename from now/index.md rename to content/now.md index 0ea6759..3c5c0da 100644 --- a/now/index.md +++ b/content/now.md @@ -1,8 +1,22 @@ -*This page shows what I'm up to at the moment, following the idea of the [/now page](https://sive.rs/nowff) introduced by [Derek Sivers](https://sive.rs/). You can find more now pages on [nownownow](https://nownownow.com/).* +--- +{ +.title = "Now", +.date = @date("2024-05-12T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "This page shows what I'm up to at the moment, following the idea of Derek Sivers.", +.tags = [], +} +--- -Last updated: 2024-05-12 +--- -Still live in Berlin where I am working fully remote. I'm appproaching the second anniversary at [Code Gaia](https://codegaia.io) now and have no plans to change any of it. +You can find more now pages on [nownownow](https://nownownow.com/). + +--- + +Still live in Berlin where I am working fully remote. I'm approaching the second anniversary at [Code Gaia](https://codegaia.io) now and have no plans to change any of it. ## Priorities diff --git a/projects/index.md b/content/projects.md similarity index 90% rename from projects/index.md rename to content/projects.md index 53569cf..4be3b46 100644 --- a/projects/index.md +++ b/content/projects.md @@ -1,7 +1,14 @@ -*My currently active projects. This is mostly about software, but might also include some TTRPG stuff, from time to time.* - -Last updated: 2024-05-17 - +--- +{ +.title = "Projects", +.date = @date("2024-05-17T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "My currently active projects. This is mostly about software, but might also include some TTRPG stuff, from time to time.", +.tags = [], +} +--- ## Homepage Overhaul > With lots of work comes lots of opportunity for productive procrastination diff --git a/setup/index.md b/content/setup.md similarity index 81% rename from setup/index.md rename to content/setup.md index 3cb2497..3a1f2c9 100644 --- a/setup/index.md +++ b/content/setup.md @@ -1,6 +1,20 @@ -*As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use. This page focusses on Hardware. For Software, check [/stack](/stack).* +--- +{ +.title = "Setup", +.date = @date("2024-05-20T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use.", +.tags = [], +} +--- -Last updated: 2024-05-20 +--- + +This page focusses on Hardware. For Software, check [/stack](/stack). + +--- I used to work on laptops without any extras, but over the years ergonomics got more and more important. Now I have a second screen, a standing desk and an ergonomic chair. My main keyboard is split in half and my pointer device is a big red ball. diff --git a/stack/index.md b/content/stack.md similarity index 94% rename from stack/index.md rename to content/stack.md index a78b8d0..922991d 100644 --- a/stack/index.md +++ b/content/stack.md @@ -1,6 +1,20 @@ -*As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use. This page focusses on Software. For Hardware, check [/setup](/setup).* +--- +{ +.title = "Stack", +.date = @date("2024-05-13T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "page.html", +.description = "As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use.", +.tags = [], +} +--- -Last updated: 2024-05-13 +--- + +This page focusses on Software. For Hardware, check [/setup](/setup). + +--- My software stack is pretty old-school. I prefer CLI applications for almost everything. The only GUI programs I usually run are browsers, image manipulators and LogSeq. diff --git a/content/til/2021-08-31.md b/content/til/2021-08-31.md new file mode 100644 index 0000000..ae2fbe9 --- /dev/null +++ b/content/til/2021-08-31.md @@ -0,0 +1,13 @@ +--- +{ +.title = "There is a HTML tag for \"Word Break Opportunity\"", +.date = @date("2021-08-31T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://www.w3schools.com/TAGS/tag_wbr.asp" }, +} +--- +For example: `Kaufhaus`. diff --git a/content/til/2021-09-03.md b/content/til/2021-09-03.md new file mode 100644 index 0000000..4244bb8 --- /dev/null +++ b/content/til/2021-09-03.md @@ -0,0 +1,12 @@ +--- +{ +.title = "Bush refused offer to discuss Osama Bin Laden handover", +.date = @date("2021-09-03T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://www.theguardian.com/world/2001/oct/14/afghanistan.terrorism5" }, +} +--- diff --git a/content/til/2021-09-04.md b/content/til/2021-09-04.md new file mode 100644 index 0000000..767b522 --- /dev/null +++ b/content/til/2021-09-04.md @@ -0,0 +1,13 @@ +--- +{ +.title = "git fetch repo_url remote_branch:new_local_branch", +.date = @date("2021-09-04T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://twitter.com/lucas59356/status/1433507127570669569" }, +} +--- +`git fetch $repo_url $remote_branch:$new_local_branch` diff --git a/content/til/2021-09-05.md b/content/til/2021-09-05.md new file mode 100644 index 0000000..dc3a8ee --- /dev/null +++ b/content/til/2021-09-05.md @@ -0,0 +1,12 @@ +--- +{ +.title = "E-Mail that isn't spam is called ham!", +.date = @date("2021-09-05T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://twitter.com/claranellist/status/1433539284779220997" }, +} +--- diff --git a/til/2022-02-22.md b/content/til/2022-02-22.md similarity index 78% rename from til/2022-02-22.md rename to content/til/2022-02-22.md index a730cdc..4292dbc 100644 --- a/til/2022-02-22.md +++ b/content/til/2022-02-22.md @@ -1,5 +1,15 @@ -# Adding aliases in vite with typescript needs the same alias in tsconfig - +--- +{ +.title = "Adding aliases in vite with typescript needs the same alias in tsconfig", +.date = @date("2022-02-22T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "" }, +} +--- For example: The following vite.config.ts: diff --git a/content/til/2022-03-22.md b/content/til/2022-03-22.md new file mode 100644 index 0000000..f515947 --- /dev/null +++ b/content/til/2022-03-22.md @@ -0,0 +1,17 @@ +--- +{ +.title = "There is a file system for EFI vars now", +.date = @date("2022-03-22T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://www.kernel.org/doc/html/latest/filesystems/efivarfs.html" }, +} +--- +On kernel updates I saw a recurring "EFI variables are not supported on this system", so I investigated and learned that the new EFI variables are provided via a file system that needs to be mounted first: + +```sh +mount -t efivarfs efivarfs /sys/firmware/efi/efivars +``` diff --git a/content/til/2022-03-28.md b/content/til/2022-03-28.md new file mode 100644 index 0000000..16b2dbd --- /dev/null +++ b/content/til/2022-03-28.md @@ -0,0 +1,18 @@ +--- +{ +.title = "pwdx command shows the working path of a process", +.date = @date("2022-03-28T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://twitter.com/mani_maranp/status/1508476973529825281)" }, +} +--- +For example: + +```sh +% pwdx 1984 +> 1984: /home/george/ttlctrl +``` diff --git a/til/2022-04-25.md b/content/til/2022-04-25.md similarity index 79% rename from til/2022-04-25.md rename to content/til/2022-04-25.md index cc6aae5..f7bfdca 100644 --- a/til/2022-04-25.md +++ b/content/til/2022-04-25.md @@ -1,5 +1,14 @@ -# Jest mocks are ...different - +--- +{ +.title = "Jest mocks are ...different", +.date = @date("2022-04-25T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +} +--- If you want to mock an imported function in Jest in a way that allows you to check if it has been called, you can not do the seemingly straighforward: ```js diff --git a/til/2022-06-15.md b/content/til/2022-06-15.md similarity index 64% rename from til/2022-06-15.md rename to content/til/2022-06-15.md index 339997a..b4a44f6 100644 --- a/til/2022-06-15.md +++ b/content/til/2022-06-15.md @@ -1,5 +1,14 @@ -# Disallowed Focussed Tests and how it saved my day - +--- +{ +.title = "Disallowed Focussed Tests and how it saved my day", +.date = @date("2022-06-15T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +} +--- Today I was about to push a focussed test. A focussed test, you ask? In Jest (and others) one can run only a specific test, by writing `it.only(...`. Pushing this to production might create some funny or not so funny side effects though. Luckily there is the `no-focussed-tests` linter rule in [eslint-plugin-jest](https://github.com/jest-community/eslint-plugin-jest). diff --git a/til/2024-05-11.md b/content/til/2024-05-11.md similarity index 83% rename from til/2024-05-11.md rename to content/til/2024-05-11.md index 57e1f5f..194fc78 100644 --- a/til/2024-05-11.md +++ b/content/til/2024-05-11.md @@ -1,7 +1,15 @@ -# Rob Pike's 5 Rules of Programming - -[source](https://users.ece.utexas.edu/~adnan/pike.html) - +--- +{ +.title = "Rob Pike's 5 Rules of Programming", +.date = @date("2024-05-11T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://users.ece.utexas.edu/~adnan/pike.html" }, +} +--- 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) diff --git a/content/til/2024-05-12.md b/content/til/2024-05-12.md new file mode 100644 index 0000000..7c06513 --- /dev/null +++ b/content/til/2024-05-12.md @@ -0,0 +1,21 @@ +--- +{ +.title = "Sort list of strings in Javascript", +.date = @date("2024-05-12T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://stackoverflow.com/questions/6712034/sort-array-by-firstname-alphabetically-in-javascript" }, +} +--- +```ts +users.sort((a, b) => a.firstname.localeCompare(b.firstname)) +``` + +or reversed order: + +```ts +users.sort((a, b) => a.firstname.localeCompare(b.firstname) * -1) +``` diff --git a/content/til/2024-05-13.md b/content/til/2024-05-13.md new file mode 100644 index 0000000..8e0b071 --- /dev/null +++ b/content/til/2024-05-13.md @@ -0,0 +1,13 @@ +--- +{ +.title = "Reading speed is usually from 100 to 260 words per minute", +.date = @date("2024-05-13T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "", +.tags = [], +.custom = { .source = "https://thereadtime.com/" }, +} +--- +With an average of 183 wpm. diff --git a/content/til/index.md b/content/til/index.md new file mode 100644 index 0000000..9e79d75 --- /dev/null +++ b/content/til/index.md @@ -0,0 +1,11 @@ +--- +{ +.title = "Today I Learned", +.date = @date("2024-05-13T00:00:00"), +.author = "koehr", +.draft = false, +.layout = "til.html", +.description = "This page contains short notes and sometimes code snippets, of interesting things I just found out.", +.tags = [], +} +--- diff --git a/dist/blog/2016-12-04-the-price-to-crack-your-password.html b/dist/blog/2016-12-04-the-price-to-crack-your-password.html deleted file mode 100644 index 53a23d8..0000000 --- a/dist/blog/2016-12-04-the-price-to-crack-your-password.html +++ /dev/null @@ -1,385 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

The price to crack your password

-

Written 2016-12-04

-

Nearly six years ago, I wrote about password complexity and showed how long it takes to crack passwords per length. You can find that article on github (in German).

- -

So, times changed and I thought about a reiteration of that topic, but instead focussing on the amount of money you need to crack the password using Amazons biggest GPU computing instances p2.16xlarge, which – at the time of writing this - costs 14.4 USD per hour. I will also compare this with the much faster Sagitta Brutalis (nice name, eh?), a 18500 USD computer optimised for GPU calculation.

-

Disclaimer

-

The numbers on this article always assume brute-force attacks, that means the attacker uses a program that tries all possible combinations until it finds the password. The numbers indicate average time to compute all possible entries. If the program simply adds up, for example, from 000000 to 999999 and your password is 000001, it will be found much faster of course.

-

How long a single calculation needs also depends on the used hashing algorithm. I will compare some of the typically used algorithms. In case you have to implement a password security system, please use BCrypt which is in most cases the best choice but NEVER try to implement something on your own! It is never ever a good idea to create an own password hashing scheme, even if it is just assembled out of existing building blocks. Use the battle-tested standard solutions. They are peer-reviewed and the safest and most robust you can get.

-

Password complexity basics

-

Password complexity is calculated out of the possible number of combinations. So a 10-character password that only contains numbers is far less complex than a mix of letters and numbers of the same length. Usually an attacker has no idea if a specific password only contains numbers or letters, but a brute-force attack will try simpler combinations first.

-

To calculate the complexity of a password, find the amount of possible combinations first:

- -

To get the complexity of your password, simply add up the numbers. A typical password contains numbers, lowercase and uppercase letters which results in 62 possible combinations per character. Add some punctuation to raise that number to 95.

-

Other ASCII Characters are the less typical ones like ÿ and Ø which add to the complexity but might be hard to type on foreign keyboards. Unicode is super hard (if not impossible) to type on some computers but would theoretically add millions of possible characters. Fancy some ਪੰਜਾਬੀ ਦੇ in your password?

-

A very important factor in the password complexity is of course also the length. And because random passwords with crazy combinations of numbers, letters and punctuation are hard to remember, some people suggest to use long combination of normal words instead.

-

The password ke1r$u@U is considered a very secure password as the time of writing this article. Its complexity calculates like this:

-

8 characters with 95 possibilites:

-

95^8 = 6634204312890625 = ~6.6×10^15

-

log2(x) calculates the complexity in bits:

-

log2(6634204312890625) = ~52.56 bits

-

Data sources

-

I didn't try the password cracking myself, and neither did I ask a friend (insert trollface here). Instead I used publicly available benchmark results:

- -

The results

-

I will compare some widely used password hashing methods, programs and -protocols for four different password complexity categories:

- -

eight numeric digits (might be your birthday)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
hashAmazonBrutalisprice to crack in less than a month
MD50.0s0.0s$0.01 (1 EC2 instance)
Skype0.0s0.0s$0.01 (1 EC2 instance)
WPA21.27m31.47s$0.30 (1 EC2 instance)
SHA2560.01s0.0s$0.01 (1 EC2 instance)
BCrypt49.1m15.77m$11.78 (1 EC2 instance)
AndroidPIN4.65s2.3s$0.02 (1 EC2 instance)
MyWallet0.34s0.25s$0.01 (1 EC2 instance)
BitcoinWallet1.98h46.26m$28.53 (1 EC2 instance)
LastPass11.07s5.4s$0.04 (1 EC2 instance)
TrueCrypt9.06m5.69m$2.18 (1 EC2 instance)
VeraCrypt4d2d$1120.45 (1 EC2 instance)
-

Conclusion: Don't do this. Never ever do this.

-

eight alphanumeric characters (eg 'pa55W0Rd')

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
hashAmazonBrutalisprice to crack in less than a month
MD549.65m18.17m$11.92 (1 EC2 instance)
Skype1.3h34.92m$18.67 (1 EC2 instance)
WPA26y3y$499500 (27 Brutalis)
SHA2564.94h2.64h$71.15 (1 EC2 instance)
BCrypt204y66y$14.7M (797 Brutalis)
AndroidPIN118d59d$37000 (2 Brutalis)
MyWallet9d7d$3003.3 (1 EC2 instance)
BitcoinWallet494y193y$43.25M (2338 Brutalis)
LastPass280d137d$92,500 (5 Brutalis)
TrueCrypt38y24y$5.3M (288 Brutalis)
VeraCrypt19381y11629y$2.62B (141574 Brutalis)
-

eigth alphanumeric characters mixed with special character (eg 'pa$$W0Rd')

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
hashAmazonBrutalisprice to crack in less than a month
MD52d9.2h~$362 (1 EC2 instance)
Skype2d17.7h~$567 (1 EC2 instance)
WPA2160y67y~$14.9M (806 Brutalis)
SHA2567d4d~$2162 (1 EC2 instance)
BCrypt6194y1989y~$448M (24,215 Brutalis)
AndroidPIN10y5y~$1.09M (59 Brutalis)
MyWallet³265d191d~$129500 (7 Brutalis)
BitcoinWallet14996y5835y~$1.3B (71,038 Brutalis)
LastPass24y12y~$2.6M (139 Brutalis)
TrueCrypt²1144y718y~$162M (8,742 Brutalis)
VeraCrypt¹588867y353320y~$79.6B (4,301,668 Brutalis)
-
    -
  1. VeraCrypt PBKDF2-HMAC-Whirlpool + XTS 512bit (super duper paranoid settings)
    2. -
  2. TrueCrypt PBKDF2-HMAC-Whirlpool + XTS 512bit
    3. -
  3. Blockchain MyWallet: https://blockchain.info/wallet/
    4. -
-

a long memorisable pass sentence ('correct horse battery staple')

-

Okay, this doesn't need a table. It takes millions of billions of years to even -crack this in MD5.

-

As illustration: The solar system needs around 225 Million years to rotate -around the core of the Milkyway. This is the so called galactic year. -The sun exists since around 20 galactic years. To crack such a password, even -when hashed in MD5 takes 3 trillion (million million) galactic years.

-

Of course nobody would ever attempt to do this. There are many possibilities to -crack a password faster. Explaining some of them would easily fill another -article, so I leave you here. Sorry.

-

Links

-

To find your way into the topic, you might visit some of the following links:

- -
-
- - - - - - diff --git a/dist/blog/2017-04-09-the-magic-0xc2.html b/dist/blog/2017-04-09-the-magic-0xc2.html deleted file mode 100644 index c5d396f..0000000 --- a/dist/blog/2017-04-09-the-magic-0xc2.html +++ /dev/null @@ -1,123 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

The Magic 0xC2

-

Written 2017-04-09

-

I built a web application with file upload functionality. Some Vue.js in the front and a CouchDB in the back. Everything should be pretty simple and straigt forward.

-

But…

- -

When I uploaded image files, they somehow got mangled. The uploaded file was bigger than the original and the new "file format" was not readable by any means. I got intrigued. What is it, that happens to the files? The changes seemed very random but reproducible, so I created a few test files to see what exactly changes and when.

-

My first file looked like this:

-
0123456789
-ABCDEFGHIJKLMNOPQRSTUVWXYZ
-abcdefghijklmnopqrstuvwxyz
-
-

To my surprise, the file stayed the same! My curiosity grew. In the meantime I found a very intriguing pattern in uploads hexdump: C3 BF C3. It was everywhere. In another file, I found similar patterns with C2. So I wrote my next test file. This time a binary file:

-
00 01 02 03 04 05 06 07  08 09 10 11 12 13 14 15 |................|
-16 17 18 19 20 21 22 23  24 25 26 27 28 29 30 31 |.... !"#$%&'()01|
-32 33 34 35 36 37 38 39  40 41 42 43 44 45 46 47 |23456789@ABCDEFG|
-48 49 50 51 52 53 54 55  56 57 58 59 60 61 62 63 |HIPQRSTUVWXY`abc|
-64 65 66 67 68 69 70 71  72 73 74 75 76 77 78 79 |defghipqrstuvwxy|
-80 81 82 83 84 85 86 87  88 89 90 91 92 93 94 95 |................|
-96 97 98 99 a0 a1 a2 a3  a4 a5 a6 a7 a8 a9 aa ab |................|
-ac ad ae af b0 b1 b2 b3  b4 b5 b6 b7 b8 b9 ba bb |................|
-00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
-
-

EDIT: As you probably already noticed, I counted up like in Base10 but it is actually Base16. So I skipped A-F until reaching A0. This might look weird but didn't affect the test.

-

The result after uploading was

-
00 01 02 03 04 05 06 07  08 09 10 11 12 13 14 15  |................|
-16 17 18 19 20 21 22 23  24 25 26 27 28 29 30 31  |.... !"#$%&'()01|
-32 33 34 35 36 37 38 39  40 41 42 43 44 45 46 47  |23456789@ABCDEFG|
-48 49 50 51 52 53 54 55  56 57 58 59 60 61 62 63  |HIPQRSTUVWXY`abc|
-64 65 66 67 68 69 70 71  72 73 74 75 76 77 78 79  |defghipqrstuvwxy|
-c2 80 c2 81 c2 82 c2 83  c2 84 c2 85 c2 86 c2 87  |................|
-c2 88 c2 89 c2 90 c2 91  c2 92 c2 93 c2 94 c2 95  |................|
-c2 96 c2 97 c2 98 c2 99  c2 a0 c2 a1 c2 a2 c2 a3  |................|
-c2 a4 c2 a5 c2 a6 c2 a7  c2 a8 c2 a9 c2 aa c2 ab  |................|
-c2 ac c2 ad c2 ae c2 af  c2 b0 c2 b1 c2 b2 c2 b3  |................|
-c2 b4 c2 b5 c2 b6 c2 b7  c2 b8 c2 b9 c2 ba c2 bb  |................|
-00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-
-

There it was again: The magic 0xC2!

-

So all bytes with a value higher than 0x79 got followed by a 0xC2. 0x79 is the ASCII code for y. This is at least what I thought. It actually is the other way around: All bytes with value 0x80 or higher got prefixed by a 0xC2! — there the scales fell from my eyes: UTF-8 encoding!

-

In UTF-8 all characters after 0x7F are at least two bytes long. They get prefixed with 0xC2 until 0xC2BF (which is the inverted question mark ¿), which is then followed by 0xC380. So what happened is, that on the way to the server, the file got encoded to UTF-8 ¯\_(ツ)_/¯

-

EDIT: Corrected some mistakes after some comments on Hackernews

-
-
- - - - - - diff --git a/dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html b/dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html deleted file mode 100644 index 6ffb7a4..0000000 --- a/dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

Vuejs Reactivity From Scratch

-

Written 2017-08-17

-

Vuejs is the star newcomer in the Javascript Framework world. People love how it makes complicated things very simple yet performant. One of the more exciting features is its seemingly magic reactivity. Plain data objects in components magically invoke a rerender when a property changes.

- - -

NOTE: This is a copy of the original article from Aug 17th, 2017. You can read the archived original on archive.org

- -

The button click invokes a function that just assigns a new value to a property. Still the template gets automagically rerendered. But we all know there is no fairydust involved, right? So how does it actually work?

-
-

The magic of getters and setters

-

With the ES5 standard JavaScript got lots of exciting new features. Some of them highly underrated and underused in my opinion. Getters and setters are an example. If you never heard of them, I would recommend you to read John Riesigs piece on them.

-

As soon as you know what getters and setters are: functions transparently called on every property access, you might already know where this goes. Boom! All the fairydust suddenly disappears.

-

Automatic getters and setters

-

Now that we at least in theory know how Vuejs realises the template data magic, let's build it ourselves for the sake of full understanding!

-

Abstract: A function that gets an object and returns one with the properties replaced by getters and setters that, on call, rerender a template. So far so good. If you are really impatient, you can find the final code in JSFiddle.

-

Let's start with a very simple approach:

- -

The function iterates through all object keys and creates a new object with getters and setters in their place. It could also directly manipulate the original object:

- -

I personally don't like to manipulate the existing object and prefer the first way.

-

Introducing: Object.defineProperty

-

Now before we go on with destroying our fantasies of fairydust computing, let's see if there is a more convenient way to what we've done for now. Here I introduce Object.defineProperty, which allows to set all possible attributes for the properties of an object. You can find a detailed description on MDN.

-

With this new knowlegde, the code can be made a bit more readable, by condensing everything into one call:

- -

All those underscores where pretty annoying anyways. I generally suggest you to read more about Object.defineProperty. It extends the range of possibilities significantly!

-

Templating for the poor

-

To be able to rerender a component on data change, we should really introduce some components that can actually render and under the right circumstances rerender a template.

- -

This code describes a very simple component, that has a data object and a render function. If this is called, it replaces the innerHTML of the given content element with the rendered output. Neat! Let's make the data reactive!

-

Reactive Component

-

As a start, it should be enough to simply make the data property reactive:

- -

Yes, that seems to be good but it doesn't really update the template. Which becomes clear after a look at line 11-14: There is no render call ever. But reactive shouldn't know about component rendering, right? Let's try a more general approach with a callback:

- -

Yeah, that works and so on but it looks like we slowly stumble away from elegance in our code. The changes in reactive() seem to be okay, but that function bind monstrosity in line 31 is something we better hide from our parents. Let's introduce a component factory before we get kicked out or end up in self hatred:

- -

Cool! That works. The createComponent() function just does all the dirty work for us and returns a nice, reactive component, that is still just a simple object. If you have that code in a local setup and run something like component.data.name = 'Ada Lovelace', then it will automagically rerender the template to show 'Hello Ada Lovelace'.

-

Nested Data structures

-

All cool and hip stuff but what happens in the following scenario:

- -

Setting deeper nested properties (line 44,45) doesn't work at all. The reason is that the reactivity only works on the first nesting level of the data object. Now you could say: Easy, we just set the whole object at once:

- -

But this is not really what we strive for, isn't it? What we need is a way that makes all nested objects reactive in a recursive way. Surprisingly, this just needs a coupe of lines:

- -

Only three lines (7-9) where added. They call reactive() on the given value in case it is an object. Now the nesting level doesn't matter anymore. REACTIVE ALL THE THINGS!!

-

Multiple Components

-

Considering that components are usually very gregarious, what happens if we find a friend for our component? Will it blend? Erm I mean, react?

- -

It does! Hooray!

-

The attentive reader might have seen the change that sneaked into line 7: Because the type of array is object, an extra check has to be made here. Otherwise the array would be transformed to a plain object with keys 0, 1, etc.

-

But what happens now when we manipulate the Array directly?

- -

Bummer! Setting the whole array works as expected but manipulating it doesn't trigger any change.

-

Reactive Arrays

-

As described in the caveats section of the Vuejs guide about list rendering, there are several …well caveats with array reactivity. It writes:

-
Due to limitations in JavaScript, Vue cannot detect the following changes to an array:
-1. When you directly set an item with the index, e.g. vm.items[indexOfItem] = newValue
-2. When you modify the length of the array, e.g. vm.items.length = newLength
-
-

Okay, fair enough. So what does happen in Vue to make Arrays reactive? Fairydust? Unfortunately yes. And this stuff is expensive! Nah, just kidding. Of course it is again no magic involved. I'm sorry my dear role-playing friends. What actually happens is that Arrays get their manipulating functions replaced by a wrapped version that notifies the component about changes. The source to this functionality is in core/observer/array.js.

-

Vuejs' approach is rather sophisticated but can be condensed down to something like what is seen in the first 24 lines here:

- -

So this is a fairly big chunk to digest. The new function reactiveArray starts with creating a copy of the original array (Remember? I don't like manipulating the original object). Then, for each function in the list of manipulative array functions the original is saved which is then replaced by a wrapper function. This wrapper function simply calls the render callback additionally to the original array function.

-

Now also lipsumComponent.data.content is not set directly anymore but uses the overwritten push method. Setting it directly wouldn't work. Fixing that leads us to the last step:

-

Reactivity on set

-

For now the setter function didn't care about the value. If it would be a nested object, its children wouldn't be reactive. That means, if you set data.x to an object {foo: 1} and then change foo data.x.foo++, the template wouldn't rerender. This should be changed:

- -

Instead of setting the plain value, reactive(value, callback) is called in line 49. This small change works only up to a certain point on its own though. The function has to decide what to do with non-objects or arrays, which happens now as a first step in reactive(). A plain non-object (remember: arrays are objects) simply gets returned as it is (line 30), arrays will be returned in their reactive version (line 31).

-

Conclusion

-

Congratulations! You made it this far or just skipped to read only the Conclusion, which is fine, I do that too sometimes.

-

In about 70 SLOC, we built a fully reactive component system. We made use of getters, setters and Object.defineProperty and learned, that I don't like to manipulate objects directly. Except for the last point, this should be valuable information that might become handy in future.

-

What else can be done you might ask? Vuejs' code is more sophisticated and handles some egde cases that I didn't mention for the sake of simplicity. For example if the yet to become reactive object has some getters and/or setters already, they would be overwritten by our simple solution. Vuejs' defineReactive uses Object.getOwnPropertyDescription to get a detailed information about the property it is going to wrap and incorporates existing getters and setters if applicable. It also ignores non-configurable (not meant to be changed at all) properties. How that works can be found in the source code.

-
-
- - - - - - diff --git a/dist/blog/2019-01-10-running-write-freely-on-arm.html b/dist/blog/2019-01-10-running-write-freely-on-arm.html deleted file mode 100644 index a6a994f..0000000 --- a/dist/blog/2019-01-10-running-write-freely-on-arm.html +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

Running writefreely 0.7 on Arm

-

Written 2019-01-10

-

This is a follow-up on -The expected tutorial: How to install WriteFreely on a Raspberry pi 3 in 10 steps. I will explain what was necessary to make cross-compiling work for newer WriteFreely versions with SQLite support.

- -

I did it! I finally got WriteFreely to run on my Arm server (check out Scaleways baremetal cloud servers).

-

It wasn't so easy because with 512MB of RAM I couldn't simply download and build the source on my webserver. Only solution: Cross compiling. Easy especially in Go, right?

-

If you read the article linked in the beginning you know how easy it could be. But as the article already mentions in an update, since Version 0.6 it is not working anymore because of the new SQLite dependency (newest version as of writing this article is 0.7).

-

With a bit of research I figured out what to do to make it work anyhow. There are two solutions. A quick (and slightly dirty) one for people who don't need SQLite support and a correct solution that needs a tad more effort.

-

Quick solution: remove SQLite support

-

SQLite support makes problems with the cross compiling because it needs some C code to be compiled. Before figuring out how to make this working with the otherwise super easy Go cross compiling, removing the feature might be a viable quick fix. For this, simply change or remove all occurences of sqlite in the Makefile:

-
diff --git a/Makefile b/Makefile
-index 5950dfd..032fd0c 100644
---- a/Makefile
-+++ b/Makefile
-@@ -13,25 +13,25 @@ IMAGE_NAME=writeas/writefreely
- all : build
- 
- build: assets deps
--	cd cmd/writefreely; $(GOBUILD) -v -tags='sqlite'
-+	cd cmd/writefreely; $(GOBUILD) -v
- 
- build-linux: deps
-    @hash xgo > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
-        $(GOGET) -u github.com/karalabe/xgo; \
-    fi
--	xgo --targets=linux/amd64, -dest build/ $(LDFLAGS) -tags='sqlite' -out writefreely ./cmd/writefreely
-+	xgo --targets=linux/amd64, -dest build/ $(LDFLAGS) -out writefreely ./cmd/writefreely
- 
- build-windows: deps
-    @hash xgo > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
-        $(GOGET) -u github.com/karalabe/xgo; \
-    fi
--	xgo --targets=windows/amd64, -dest build/ $(LDFLAGS) -tags='sqlite' -out writefreely ./cmd/writefreely
-+	xgo --targets=windows/amd64, -dest build/ $(LDFLAGS) -out writefreely ./cmd/writefreely
- 
- build-darwin: deps
-    @hash xgo > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
-        $(GOGET) -u github.com/karalabe/xgo; \
-    fi
--	xgo --targets=darwin/amd64, -dest build/ $(LDFLAGS) -tags='sqlite' -out writefreely ./cmd/writefreely
-+	xgo --targets=darwin/amd64, -dest build/ $(LDFLAGS) -out writefreely ./cmd/writefreely
- 
- build-docker :
-    $(DOCKERCMD) build -t $(IMAGE_NAME):latest -t $(IMAGE_NAME):$(GITREV) .
-@@ -40,11 +40,11 @@ test:
-    $(GOTEST) -v ./...
- 
- run: dev-assets
--	$(GOINSTALL) -tags='sqlite' ./...
-+	$(GOINSTALL) ./...
-    $(BINARY_NAME) --debug
- 
- deps :
--	$(GOGET) -tags='sqlite' -v ./...
-+	$(GOGET) -v ./...
- 
- install : build
-    cmd/writefreely/$(BINARY_NAME) --gen-keys
-@@ -77,10 +77,10 @@ ui : force_look
-    cd less/; $(MAKE) $(MFLAGS)
- 
- assets : generate
--	go-bindata -pkg writefreely -ignore=\\.gitignore schema.sql sqlite.sql
-+	go-bindata -pkg writefreely -ignore=\\.gitignore schema.sql
- 
- dev-assets : generate
--	go-bindata -pkg writefreely -ignore=\\.gitignore -debug schema.sql sqlite.sql
-+	go-bindata -pkg writefreely -ignore=\\.gitignore -debug schema.sql
- 
- generate :
-    @hash go-bindata > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
-
-

Now just go on as described in the original article and it should work:

-
env GOARCH=arm GOARM=7 go get github.com/writeas/writefreely/cmd/writefreely
-
-

The correct solution

-

To get WriteFreely cross compiled with SQLite support, a C cross compiler is needed. Void Linux, the distribution of my choice, offers a bunch of packages for all kind of architectures. They are called for example cross-armv7l-linux-gnueabihf (ARMv7), cross-arm-linux-gnueabihf (ARMv6) or cross-arm-linux-gnueabi (ARMv5). I found similar packages in AUR (for Arch Linux).

-

As soon as the corresponding cross compiler is found, go can be told to use it:

-
env CGO_ENABLED=1 CC=armv7l-linux-gnueabihf-gcc GOOS=linux GOARCH=arm GOARM=7 make
-
-

The environment variables used are:

-

CGO_ENABLED=1 should be obvious. It tells Go to enable the C compilation.

-

CC=armv... tells Go which C compiler to use. Usually this would be just gcc. In this case it is the name of the cross compiler. Please set it to the compiler for your target platform. I'm going to use ARMv7 examples here. It is the name of a directory found in /usr/, eg /usr/armv7l-linux-gnueabihf. Initially that failed for me though because it expected to find a file ./lib/libc.so which ended up in another subfolder /usr/. So I cheated a bit and did:

-
# You might not need to do this on your platform.
-sudo ln -s /usr/armv7l-linux-gnueabihf/usr/lib /usr/armv7l-linux-gnueabihf/lib
-
-

GOOS=linux GOARCH=arm are the same as in the original article.

-

GOARM=7 is optional, even on an actual ARMv7. It enables some register optimizations that only work on ARMv7.

-

And finally make is called. This is short for make all which should do everything necessary.

-

Not all files are necessary to be transferred to the Server or RaspberryPi. What I did after some experimentation was:

-
# after building everything create a package
-mkdir writefreely-arm
-cp -r templates pages static writefreely-arm
-mkdir writefreely-arm/keys # fun fact: key generation crashes without this
-cp cmd/writefreely/writefreely writefreely-arm
-tar cvzf writefreely-arm.tgz writefreely-arm
-
-# copy that package to the server
-scp writefreely-arm.tgz you@yourserver.tld:~
-
-# ssh into the server and unpack everything
-ssh you@yourserver.tld
-tar czf writefreely-arm.tgz
-cd writefreely-arm
-
-# generate config, keys and database
-./writefreely -config # starts interactive configuration
-
-# This should lead you through all necessary steps
-# like filling the config, generating keys, generating database tables
-# run `./writefreely --help` to learn more if something is missing.
-
-

Now ./writefreely should run an empty blog at the specified port.

-

Have fun!

-
-
- - - - - - diff --git a/dist/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.html b/dist/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.html deleted file mode 100644 index 02fb7b5..0000000 --- a/dist/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

Use OpenBSDs Spleen bitmap font in Linux

-

Written 2019-01-10

-

Yesterday Frederic Cambus changed the default console font in OpenBSD to his self made font Spleen as written in this BSD Journal article.

- -

To be totally honest, I stopped thinking about TTY (aka console) fonts a long time ago. It just happened to get interesting again when I got a HiRes screen and suddenly a magnifying glass was necessary to read the TTY. Yes I am one of those people who still deny the existence of graphical installers. If you want to change my mind, feel free to write me.

-

Anyhow, I figured that Spleen is pretty and useful because it offers glyphs with sizes up to 32x64. Typical fonts in Void Linux are 8x16 or similar, which is very small on high DPI screens. But how to use them? Spleen comes in strange formats like BDF or .dfont but we need another strange format called PSFU. If we look at the description that comes with Spleen we only get tought how to make yet another strange format called PCF. Puh, so confusing. Fonts must have been a real pain back in the "good old times".

-

If you managed to read this until this point, I congratulate you. You won a short list of commands:

-
# assuming bdf2psf is installed
-FONTDIR=/usr/share/kbd/consolefonts   # or anything you want
-SPLEENDIR=$HOME/src/spleen             # or whereever you want the repo
-EQUIV=/usr/share/bdf2psf/standard.equivalents # check bdf2psf manpage
-FONTSET=/usr/share/bdf2psf/fontsets/Uni1.512 # check bdf2psf manpage
-
-git clone https://github.com/fcambus/spleen.git $SPLEENDIR
-
-for x in 12x24 16x32 32x64 5x8 8x16 # do it for all available sizes
-do
-    bdf2psf --fb \
-        ${SPLEENDIR}/spleen-${x}.bdf \
-        $EQUIV $FONTSET 512 \
-        ${FONTDIR}/spleen-${x}.psfu
-done
-
-# assuming you're in the TTY
-setfont ${SPLEENDIR}/spleen-16x32.psfu
-
-

That worked for me! Except spleen-32x64 didn't work for me. It might be too big for Linux TTYs but would be too big anyways. Lets wait for 8K displays.

-
-
- - - - - - diff --git a/dist/blog/2019-05-03-freddy-vs-json.html b/dist/blog/2019-05-03-freddy-vs-json.html deleted file mode 100644 index 3f066aa..0000000 --- a/dist/blog/2019-05-03-freddy-vs-json.html +++ /dev/null @@ -1,674 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

Freddy vs JSON: how to make a top-down shooter

-

Written 2019-05-03

-

I will tell you how I created a simple top-down shooter in JavaScript without using any additional libraries. But this article is not replicating the full game but instead tries to show which steps to take to start writing a game from scratch.

- -

A couple of years ago (Oh it's almost a decade! Am I that old already?), when the Canvas API got widely adopted by most browsers, I started experimenting with it. The fascination was high and I immediately tried to use it for interactive toys and games.

-

Of course, the games I made (and make) are usually not very sophisticated. That is mainly because I create them only for fun and without much eye-candy or even sound. What really fascinates me is the underlying mechanics. Otherwise, I could just use one of those awesome game engines, that exist already.

-

To share some of the fun, I created a tiny top down shooter for a tech session in my company (we're hiring, btw). The result can be found on Github. I commented the code well so it should be quite helpful to just read it. But if you want to know how I created the game step-by-step, this article is for you.

-

The Game

-

To give you an impression of what I created:

-

screenshot

-

The little gray box is your ship. You are controlling the little gray box with either WASD or Arrow keys and you can shoot tiny yellow boxes at your enemies — the red boxes — by pressing Space or Enter. The enemies shoot back though. They don't really aim well, but at some point they'll flood the screen with tiny red boxes. If they hit you, they hurt. Every time you get hurt you shrink, until you completely disappear. The same happens with your opponents.

-

Preconditions

-

This post is not about the game itself but about the underlying mechanics and some of the tricks used to make it work. My intention is to provide an entry for understanding more complex game development for people with some existing programming experience. The following things are helpful to fully understand everything:

-

Fundamental Game Engine Mechanics

-

Most — if not all — game engines have the same fundamental building blocks:

- -

The Canvas Element

-

The Canvas element allows you to handle pixel based data directly inside the browser. It gives you a few functions to draw primitives. It is easy to draw, for example, a blue rectangle but you need more than one action to draw a triangle; to draw a circle you need to know how to use arcs.

-

Exactly because drawing rectangles is the easiest and fastest thing to do with the Canvas API, I used them for everything in Freddy vs JSON. That keeps the complexities of drawing more exciting patterns or graphics away and helps focus on the actual game mechanics. This means, after initializing the canvas besides setting colors we only use two functions:

-
const ctx = canvas.getContext('2d') // this is the graphics context
-ctx.fillStyle = '#123456'           // use color #123456
-
-ctx.fillText(text, x, y)            // write 'text' at coords x, y
-ctx.fillRect(x, y, width, height)   // draw filled rectangle
-
-

Step One: Some HTML and an initialized Canvas

-

Because the code is going to run in the browser, some HTML is necessary. A minimal set would be just the following two lines:

-
<canvas id="canvas" />
-<script src="./app.js"></script>
-
-

This works but of course some styling would be great. And maybe having a title? Check out a complete version on Github.

-

Initializing a Canvas is also pretty simple. Inside app.js following lines are necessary:

-
const canvas = document.getElementById('canvas')
-// you can set height and width in HTML, too
-canvas.width = 960
-canvas.height = 540
-const ctx = canvas.getContext('2d')
-
-

I chose rather arbitrary values for width and height. Feel free to change them to your liking. Just know that higher values obviously will result in more work for your computer.

-

Step Two: Game Mode / States

-

To avoid creating a big ball of mud it is common to use a state machine. The idea is to describe the high level states and their valid transitions and using a central state handler to control them.

-

There libraries that help with state machines, but it is also not too hard to create this yourself. In the game I created I used a very simple state machine implementation: The possible states and their transitions are described in Enum-like objects. Here some code to illustrate the idea. The code uses some rather new language features: Symbols and Computed Property Names.

-
const STATE = {
-  start: Symbol('start'),  // the welcome screen
-  game: Symbol('game'),    // the actual game
-  pause: Symbol('pause'),  // paused game
-  end: Symbol('end')       // after losing the game
-}
-
-const STATE_TRANSITION = {
-  [STATE.start]: STATE.game, // Welcome screen => Game
-  [STATE.game]: STATE.pause, // Game => Pause
-  [STATE.pause]: STATE.game, // Pause => Game
-  [STATE.end]: STATE.start   // End screen => Welcome screen
-}
-
-

This is not a full state machine but does the job. For the sake of simplicity I violate the state machine in one occasion though: There is no transition from the running game to the end of the game. This means I have to jump directly, without using the state handler, to the end screen after the player dies. But this saved me from a lot of complexity. Now the state control logic is effectively only one line:

-
newState = STATE_TRANSITION[currentState]
-
-

Freddy vs JSON uses this in the click handler. A click into the canvas changes the state from welcome screen to the actual game, pauses and un-pauses the game and brings you back to the welcome screen after losing. All that in only one line. The new state is set to a variable that is respected by the central update loop. More on that later.

-

Of course much more could be done with a state. For example weapon or ship upgrades could be realised. The game could transition towards higher difficulty levels and get special game states like an upgrade shop or transfer animations between stages. Your imagination is the limit. And the amount of lines in your state handler, I guess.

-

Step Three: Data Handling

-

Games usually have to handle a lot of information. Some examples are the position and health of the player, the position and health of each enemy, the position of each single bullet that is currently flying around and the amount of hits the player landed so far.

-

JavaScript allows different ways to handle this. Of course, the state could just be global. But we all (should) know that global variables are the root of all evil. Global constants are okay because they stay predictable. Just don't use global variables. If you're still not convinced, please read this entry on stackexchange.

-

Instead of global variables, you can put everything into the same scope. A simple example is shown next. The following code examples use template literals, a new language feature. Learn more about template literals here.

-
function Game (canvas) {  // the scope
-  const ctx = canvas.getContext('2d')
-  const playerMaxHealth = 10
-  let playerHealth = 10
-
-  function handleThings () {
-    ctx.fillText(`HP: ${playerHealth} / ${playerMaxHealth}`, 10, 10)
-  }
-}
-
-

This is nice because you have easy access just like with global variables without actually using global variables. It still opens the door to potential problems if you only have one big scope for everything, but the first game is probably small enough to get away with not thinking about this too much.

-

Another way is to use classes:

-
class Game {
-  constructor (canvas) {
-    this.ctx = canvas.getContext('2d')
-    this.playerMaxHealth = 10
-    this.playerHealth = 10
-  }
-
-  handleThings () {
-    const max = this.playerMaxHealth
-    const hp = this.playerHealth
-    ctx.fillText(`HP: ${hp} / ${max}`, 10, 10)
-  }
-}
-
-

That looks like a bit more boilerplate but classes are good to encapsulate common functionality. They get even better if your game grows and you want to stay sane. But in JavaScript they are just syntactical sugar. Everything can be achieved with functions and function scopes. So it is up to you, what you use. The two last code examples are essentially the same thing.

-

Now that we decided on how to save all the data (Freddy vs JSON uses a class so I'll use classes here too) we can further structure it... or not. Freddy vs JSON saves everything flat. That means for example that each player attribute gets its own variable instead of using a player object that contains a lot of properties. The latter is probably more readable so you might want to go this path. Object access is also pretty fast nowadays so there is probably not a noticeable difference if you write this.player.health instead of this.playerHealth. If you are really serious about performance though, you might want to investigate this topic further. You can check out my jsperf experiment for a start.

-

Data manipulation happens in the update loop or when handling events. The next steps explain these topics further.

-

Step Four: The Main Loop

-

If event based changes are enough, like on a website, a separate loop wouldn't be necessary. The user clicks somewhere, which triggers an event that updates something and eventually re-renders a part of the page. But in a game some things happen without direct user interaction. Enemies come into the scene and shoot at you, there might be some background animation, music plays, and so on. To make all this possible a game needs an endlessly running loop which repeatedly calls a function that checks and updates the status of everything. And to make things awesomely smooth it should call this function in a consistent interval — at least thirty, better sixty times per second.

-

The following code examples use another rather new language feature called Arrow Functions.

-

Typical approaches to run a function in an regular interval would include the usage of setInterval:

-
let someValue = 23
-setInterval(() => {
-  someValue++
-}, 16)
-
-

Or setTimeout

-
let someValue = 42
-
-function update () {
-  someValue++
-  setTimeout(update, 16)
-}
-
-update()
-
-

The first version just runs the function endlessly every sixteen milliseconds (which makes sixty-two and a half times per second), regardless of the time the function itself needs or if is done already. The second version does its potentially long running job before it sets a timer to start itself again after sixteen milliseconds.

-

The first version is especially problematic. If a single run needs more than sixteen milliseconds, it runs another time before the first run finished, which might lead to a lot of fun, but not necessarily to any useful result. The second version is clearly better here because it only sets the next timeout after doing everything else. But there is still a problem: Independent of the time the function needs to run it will wait an additional sixteen milliseconds to run the function again.

-

To mitigate this, the function needs to know how long it took to do its job and then substract that value from the waiting time:

-
let lastRun
-let someValue = 42
-
-function update () {
-  someValue++
-  const duration = Date.now() - lastRun
-  const time = duration > 16 ? 0 : 16 - time
-  setTimeout(update, time)
-  lastRun = Date.now()
-}
-
-lastRun = Date.now()
-update()
-
-

Date.now() returns the current time in milliseconds. With this information we can figure out how much time has passed since the last run. If more than sixteen milliseconds have passed since then just start the update immediately and crush that poor computer (or better slow down the execution time and be nice to the computer), otherwise wait as long as necessary to stay at around sixty runs per second.

-

Please note that Date.now() is not the best way to measure performance. To learn more about performance and high resolution time measurement, check out: https://developer.mozilla.org/en-US/docs/Web/API/Performance

-

Cool. This way you can also slow everything down to a chill thirty frames per second by setting the interval to thirty-three milliseconds. But lets not go that path. Lets do what the cool kids with their shiny new browsers do. Lets use requestAnimationFrame.

-

requestAnimationFrame takes your update function as an argument and will call it right before the next repaint. It also gives you the timestamp of the last call, so that you don't have to ask for another one, which potentially impacts your performance. Lets get down to the details:

-
function update () {
-  /* do some heavy calculations */
-  requestAnimationFrame(update)
-}
-
-update()
-
-

This is the simplest version. It runs your update function as close as possible to the next repaint. This means it usually runs sixty times per second, but the rate might be different depending on the screen refresh rate of the computer it runs on. If your function takes longer than the duration between screen refreshes, it will simply skip some repaints because it is not asking for a repaint before it is finished. This way it will always stay in line with the refresh rate.

-

A function that does a lot of stuff might not need to run that often. Thirty times per second is usually enough to make things appear smooth and some other calculations might not be necessary every time. This brings us back to the timed function we had before. In this version we use the timestamp that requestAnimationFrame is giving us when calling our function:

-
let lastRun
-
-function update (stamp) {
-  /* heavy work here */
-  lastRun = stamp
-
-  // maybe 30fps are enough so the code has 33ms to do its work
-  if (stamp - lastRun >= 33) {
-    requestAnimationFrame(update)
-  }
-}
-
-// makes sure the function gets a timestamp
-requestAnimationFrame(update)
-
-

Step Five: Event Handling

-

People usually want to feel like they are in control of what they are doing. This brings us to a point where the game needs to handle input from the user. Input can be either a mouse movement, a mouse click or a key press. Key presses are also separated into pressing and releasing the key. I'll explain why later in this section.

-

If your game is the only thing running on that page (and it deserves that much attention, doesn't it?) input events can simply be bound to document. Otherwise they need to be bound to the canvas event directly. The latter can be more complicated with key events because key events work best with actual input fields. This means you need to insert one into the page, and make sure it stays focused so that it gets the events. Each click into the canvas would make it lose focus. To avoid that, you can use the following hack:

-
inputElement.onblur = () => inputElement.focus()
-
-

Or you simply put everything to its own page and bind the event listeners to document. It makes your life much easier.

-

Side note: People might wonder why I don't use addEventListener. Please use it if it makes you feel better. I don't use it here for simplicity reasons and it will not be a problem as long as each element has exactly one event listener for each event type.

-

Mouse Movement

-

Mouse movements are not really used in Freddy vs JSON but this post wouldn't be complete without explaining them. So this is how you do it:

-
canvas.onmousemove = mouseMoveEvent => {
-  doSomethingWithThat(mouseMoveEvent)
-}
-
-

This will be executed on every little movement of the mouse as long as it is on top of the canvas. Usually you want to debounce that event handler because the event might fire at crazy rates. Another way would be to use it only for something very simple, like to save the mouse coordinates. That information can be used in a function that is not tied to the event firing, like our update function:

-
class Game {
-  constructor (canvas) {
-    // don't forget to set canvas width and height,
-    // if you don't do it, it will set to rather
-    // small default values
-    this.ctx = canvas.getContext('2d')
-    this.mouseX = 0
-    this.mouseY = 0
-
-    // gets called at every little mouse movement
-    canvas.onmousemove = event => {
-      this.mouseX = event.offsetX
-      this.mouseY = event.offsetY
-    }
-
-    this.update()
-  }
-
-  // gets called at each repaint
-  update () {
-    requestAnimationFrame(() => this.update())
-    this.fillRect('green', this.mouseX, this.mouseY, 2, 2)
-  }
-}
-
-

The MouseEvent object contains a lot more useful information. I suggest you to check out the link and read about it.

-

This should draw two pixel wide boxes wherever you touch the canvas with your mouse. Yeah, a drawing program in ten lines! Photoshop, we're coming for you!

-

Mouse Clicks

-

But lets get back to reality. Mouse clicks are another important interaction:

-
canvas.onclick = mouseClickEvent => {
-  doSomethingWithThat(mouseClickEvent)
-}
-
-

The event object again contains all kind of useful information. It is the same type of object that you get from mouse movement. Makes life simpler, doesn't it?

-

Now to make use of the mouse clicks, lets adapt the former code example:

-
class Game {
-  constructor (canvas) {
-    // set canvas.width and canvas.height here
-    this.ctx = canvas.getContext('2d')
-    this.mouseX = 0
-    this.mouseY = 0
-    this.drawing = false
-
-    canvas.onmousemove = event => {
-      this.mouseX = event.offsetX
-      this.mouseY = event.offsetY
-    }
-    canvas.onmousedown = () => {
-      this.drawing = true
-    }
-    canvas.onmouseup = () => {
-      this.drawing = false
-    }
-
-    this.update()
-  }
-
-  update () {
-    requestAnimationFrame(() => this.update())
-    if (this.drawing) {
-      this.fillRect('green', this.mouseX, this.mouseY, 2, 2)
-    }
-  }
-}
-
-

Check it out on CodeSandbox

-

Now the boxes are only drawn while holding down the mouse button. Boom, one step closer to the ease of use of Photoshop! It is incredible, what you can do with it already. Just check out this incredible piece of art:

-

incredible piece of art

-

Key Events

-

The last important input comes from key presses. Okay, it is not really the last input type. Other ones would come from joysticks or gamepads. But there are some old-school people like me who still prefer using the keyboard to navigate their space ship.

-

Input handling is theoretically simple but in practice it is everything but. That's why this section explains not only how key events work but also how to get them right. Look forward to event handling, the relationship between velocity and acceleration, and frame rate agnostic timing...

-

The simplest version of key event handling looks like this:

-
document.onkeypress = keyPressEvent => {
-  doSomethingWithThat(keyPressEvent)
-}
-
-

But keypress is deprecated and should not be used. It is anyways better to separate the keyPress into two events: KeyDown and KeyUp and I'll explain why.

-

For now imagine you have that awesome space ship in the middle of the screen and want to make it fly to the right if the user presses d or ArrowRight:

-
class Game {
-  constructor(canvas, width, height) {
-    // we'll need those values
-    this.width = canvas.width = width;
-    this.height = canvas.height = height;
-    this.ctx = canvas.getContext("2d");
-
-    this.shipSize = 10;
-    this.shipHalf = this.shipSize / 2.0; // you'll need that a lot
-
-    // position the ship in the center of the canvas
-    this.shipX = width / 2.0 - this.shipHalf;
-    this.shipY = height / 2.0 - this.shipHalf;
-
-    // event is a KeyboardEvent:
-    // https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
-    document.onkeypress = event => {
-      const key = event.key;
-      if (key === "d" || key === "ArrowRight") {
-        this.shipX++;
-      }
-    };
-
-    this.update();
-  }
-
-  // convenience matters
-  rect(color, x, y, w, h) {
-    this.ctx.fillStyle = color;
-    this.ctx.fillRect(x, y, w, h);
-  }
-
-  update() {
-    // clean the canvas
-    this.rect("black", 0, 0, this.width, this.height);
-
-    // get everything we need to draw the ship
-    const size = this.shipSize;
-    const x = this.shipX - this.shipHalf;
-    const y = this.shipY - this.shipHalf;
-
-    // draw the ship
-    this.rect("green", x, y, size, size);
-
-    // redraw as fast as it makes sense
-    requestAnimationFrame(() => this.update());
-  }
-}
-
-

check it out on CodeSandbox

-

Okay, that is kinda working, at least if you press d. But the arrow key is somehow not working and the ship's movement feels a bit jumpy. That doesn't seem to be optimal.

-

The problem is that we're relying on repeated key events. If you press and hold a key, the keypress event is repeated a couple of times per second, depending on how you set your key repeat rate. There is no way to use that for a smooth movement because we can not find out how fast the users keys are repeating. Sure, we could try to measure the repeat rate, hoping the user holds the key long enough. But let's try to be smarter than that.

-

Lets recap: We hold the key, the ship moves. We leave the key, the movement stops. That is what we want. What a happy coincidence that these two events have ...erm.. events:

-
class Game {
-  constructor(canvas, width, height) {
-    // we'll need those values
-    this.width = canvas.width = width;
-    this.height = canvas.height = height;
-    this.ctx = canvas.getContext("2d");
-
-    this.shipSize = 10;
-    this.shipHalf = this.shipSize / 2.0; // you'll need that a lot
-
-    // position the ship in the center of the canvas
-    this.shipX = width / 2.0 - this.shipHalf;
-    this.shipY = height / 2.0 - this.shipHalf;
-
-    this.shipMoves = false;
-
-    // key is pressed down
-    document.onkeydown = event => {
-      const key = event.key;
-      switch (key) {
-        case "d":
-        case "ArrowRight":
-          this.shipMoves = "right";
-          break;
-        case "a":
-        case "ArrowLeft":
-          this.shipMoves = "left";
-          break;
-        case "w":
-        case "ArrowUp":
-          this.shipMoves = "up";
-          break;
-        case "s":
-        case "ArrowDown":
-          this.shipMoves = "down";
-          break;
-      }
-    };
-
-    document.onkeyup = () => {
-      this.shipMoves = false;
-    };
-
-    this.update();
-  }
-
-  // convenience matters
-  rect(color, x, y, w, h) {
-    this.ctx.fillStyle = color;
-    this.ctx.fillRect(x, y, w, h);
-  }
-
-  update() {
-    // move the ship
-    if (this.shipMoves) {
-      if (this.shipMoves === "right") this.shipX++;
-      else if (this.shipMoves === "left") this.shipX--;
-      else if (this.shipMoves === "up") this.shipY--;
-      else if (this.shipMoves === "down") this.shipY++;
-    }
-
-    // clean the canvas
-    this.rect("black", 0, 0, this.width, this.height);
-
-    // get everything we need to draw the ship
-    const size = this.shipSize;
-    const x = this.shipX - this.shipHalf;
-    const y = this.shipY - this.shipHalf;
-
-    // draw the ship
-    this.rect("green", x, y, size, size);
-
-    // redraw as fast as it makes sense
-    requestAnimationFrame(() => this.update());
-  }
-}
-
-

check it out on CodeSandbox

-

I felt like adding all directions right away. Now the movement itself is decoupled from the key events. Instead of changing the coordinates directly on each event, a value is set to a movement direction and the main loop takes care of adapting the coordinates. That's great because we don't care about any key repeat rates anymore.

-

But there are still some problems here. First of all, the ship can only move in one direction at a time. Instead it should always be able to move in two directions at a time, like up- and leftwards. Then the movement stops if the switch from one key to another is too fast. That might happen in a heated situation between your ship and the enemies bullets. Also the movement is bound to the frame rate. If the frame rate drops or the screen refreshes on a different rate on the players computer, your ship becomes slower or faster. And last but not least the ship simply jumps to full speed and back to zero. For a more natural feeling it should instead accelerate and decelerate.

-

Lots of work. Lets tackle the problems one by one:

-

Bidirectional movements are easy to do. We just need a second variable. And to simplify things even more, we can set these variables to numbers instead of identifying strings. Here you see why:

-
class Game {
-  constructor(canvas, width, height) {
-    /* ... same as before ... */
-
-    this.shipMovesHorizontal = 0;
-    this.shipMovesVertical = 0;
-
-    // this time, the values are either positive or negative
-    // depending on the movement direction
-    document.onkeydown = event => {
-      const key = event.key;
-      switch (key) {
-        case "d":
-        case "ArrowRight":
-          this.shipMovesHorizontal = 1;
-          break;
-        case "a":
-        case "ArrowLeft":
-          this.shipMovesHorizontal = -1;
-          break;
-        case "w":
-        case "ArrowUp":
-          this.shipMovesVertical = -1;
-          break;
-        case "s":
-        case "ArrowDown":
-          this.shipMovesVertical = 1;
-          break;
-      }
-    };
-
-    // to make this work, we need to reset movement
-    // but this time depending on the keys
-    document.onkeyup = event => {
-      const key = event.key;
-      switch (key) {
-        case "d":
-        case "ArrowRight":
-        case "a":
-        case "ArrowLeft":
-          this.shipMovesHorizontal = 0;
-          break;
-        case "w":
-        case "ArrowUp":
-        case "s":
-        case "ArrowDown":
-          this.shipMovesVertical = 0;
-          break;
-      }
-    };
-
-    this.update();
-  }
-
-  /* more functions here */
-
-  update() {
-    // move the ship
-    this.shipX += this.shipMovesHorizontal;
-    this.shipY += this.shipMovesVertical;
-
-    /* drawing stuff */
-  }
-}
-
-

Find the full version on CodeSandbox

-

This not only allows the ship to move in two directions at the same time, it also simplifies everything. But there's still the problem, that fast key presses don't get recognized well.

-

What actually happens in those stressful moments is correct from the code's point of view: If a key of the same dimension (horizontal or vertical) is pressed, set the movement direction, if it is released set movement to zero. But humans are not very exact. They might press the left arrow (or a) a split second before they fully released the right arrow (or d). This way, the function switches the movement direction for that split second but then stops because of the released key.

-

To fix this, the keyup handler needs a bit more logic:

-
document.onkeyup = event => {
-  const key = event.key;
-  switch (key) {
-    case "d":
-    case "ArrowRight":
-      if (this.shipMovesHorizontal > 0) {
-        this.shipMovesHorizontal = 0;
-      }
-      break;
-    case "a":
-    case "ArrowLeft":
-      if (this.shipMovesHorizontal < 0) {
-        this.shipMovesHorizontal = 0;
-      }
-      break;
-    case "w":
-    case "ArrowUp":
-      if (this.shipMovesVertical < 0) {
-        this.shipMovesVertical = 0;
-      }
-      break;
-    case "s":
-    case "ArrowDown":
-      if (this.shipMovesVertical > 0) {
-        this.shipMovesVertical = 0;
-      }
-      break;
-  }
-};
-
-

Check out the full code at CodeSandbox

-

Much better, isn't it? Whatever we do, the ship is flying in the expected direction. Time to tackle the last problems. Lets go with the easier one first: Acceleration.

-

For now, the ship simply has a fixed speed. Lets make it faster first, because we want action, right? For that, we'll define the maximum speed of the ship:

-
this.shipSpeed = 5  // pixel per frame
-
-

And use it as a multiplicator:

-
  update() {
-    // move the ship
-    this.shipX += this.shipMovesHorizontal * this.shipSpeed;
-    this.shipY += this.shipMovesVertical * this.shipSpeed;
-
-    /* drawing stuff */
-  }
-
-

And now, instead of jumping to the full speed, we update velocity values per axis:

-
  constructor () {
-    /* ... */
-    this.shipSpeed = 5
-    this.shipVelocityHorizontal = 0
-    this.shipVelocityVertical = 0
-    /* ... */
-  }
-
-  /* ...more stuff... */
-
-  update () {
-    // accelerate the ship
-    const maxSpeed = this.shipSpeed;
-    // speed can be negative (left/up) or positive (right/down)
-    let currentAbsSpeedH = Math.abs(this.shipVelocityHorizontal);
-    let currentAbsSpeedV = Math.abs(this.shipVelocityVertical);
-
-    // increase ship speed until it reaches maximum
-    if (this.shipMovesHorizontal && currentAbsSpeedH < maxSpeed) {
-      this.shipVelocityHorizontal += this.shipMovesHorizontal * 0.2;
-    } else {
-      this.shipVelocityHorizontal = 0
-    }
-    if (this.shipMovesVertical && currentAbsSpeedV < maxSpeed) {
-      this.shipVelocityVertical += this.shipMovesVertical * 0.2;
-    } else {
-      this.shipVelocityVertical = 0
-    }
-
-    /* drawing stuff */
-  }
-
-

This slowly accelerates the ship until full speed. But it still stops immediately. To decelerate the ship and also make sure the ship actually stops and doesn't randomly float around due to rounding errors, some more lines are needed. You'll find everything in the final version on CodeSandbox.

-

Now the last problem has be solved: Framerate-dependent movement. For now, all the values are tweaked in a way that they work nicely at the current speed. Lets assume at sixty frames per second. Now that poor computer has to install updates in the background or maybe it is just Chrome getting messy. Maybe the player has a different screen refresh rate. The result is a drop or increase of the frame rate. Lets take a drop down to the half as an example. Thirty frames per second is still completely smooth for almost everything. Movies have thirty frames per second and they do just fine, right? Yet our ship is suddenly only half as fast and that difference is very noticeable.

-

To prevent this, the movement needs to be based on actual time. Instead of a fixed value added to the coordinates each frame, a value is added that respects the time passed since the last update. The same is necessary for velocity changes. So instead of the more or less arbitrary five pixels at sixty frames per second we set the value in pixels per millisecond because everything is in millisecond precision.

-
5px*60/s = 300px/s = 0.3px/ms
-
-

This makes the next step rather easy: Count the amount of milliseconds since the last update and multiply it with the maximum speed and acceleration values:

-
  constructor () {
-    /* ... */
-    this.shipSpeed = 0.3  // pixels per millisecond
-    // how fast the ship accelerates
-    this.shipAcceleration = this.shipSpeed / 10.0
-    this.shipVelocityHorizontal = 0
-    this.shipVelocityVertical = 0
-    /* ... */
-
-    // this should always happen right before the first update call
-    // performance.now gives a high precision time value and is also
-    // used by requestAnimationFrame
-    this.lastDraw = performance.now()
-    requestAnimationFrame(stamp => this.update(stamp))
-  }
-
-  /* ...more stuff... */
-
-  // See the main loop section if "stamp" looks fishy to you.
-  update (stamp) {
-    // calculate how much time passed since last update
-    const timePassed = stamp - this.lastDraw
-    this.lastDraw = stamp
-
-    // accelerate the ship
-    const maxSpeed = this.shipSpeed * timePassed;
-    const accel = this.shipAcceleration * timePassed;
-
-    let currentAbsSpeedH = Math.abs(this.shipVelocityHorizontal);
-    let currentAbsSpeedV = Math.abs(this.shipVelocityVertical);
-
-    if (this.shipMovesHorizontal && currentAbsSpeedH < maxSpeed) {
-      const acceleration = 
-      this.shipVelocityHorizontal += this.shipMovesHorizontal * accel;
-    } else {
-      this.shipVelocityHorizontal = 0
-    }
-    if (this.shipMovesVertical && currentAbsSpeedV < maxSpeed) {
-      this.shipVelocityVertical += this.shipMovesVertical * accel;
-    } else {
-      this.shipVelocityVertical = 0
-    }
-
-    /* drawing stuff */
-  }
-
-

Check out the full version at CodeSandbox

-

If everything is the same as before you did everything right. Now independent of the frame rate you ship will move five pixels per millisecond. Unfortunately I didn't find a good way to test that except for changing the refresh rate of your screen or overwriting requestAnimationFrame so I left this part out of the post.

-

The End

-

Congratulations, you made a fully moving ship. This Post ends here but of course there is so much more to learn about game development. Freddy vs JSON adds some more elements but uses only techniques described in this article. Feel free to check out its source code and create a ton of games like it. Or completely different ones. Be creative and enjoy to use what you've just learned.

-
-
- - - - - - diff --git a/dist/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.html b/dist/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.html deleted file mode 100644 index e34581a..0000000 --- a/dist/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.html +++ /dev/null @@ -1,277 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

A store implementation from scratch using Vue3's Composition API

-

Written 2020-06-29

-

I've built a store implementation that allows name-spaced actions and helps with the separation of concerns. The new Composition API in Vue3 also allows completely new, convenient ways of using it.

- -
-

This article is crossposted on dev.to. Feel free to join the discussion there.

-
-

At some point I started moving a side project over to Vue3 (which is still in beta). The side project is in a rather early stage and so I decided to rebuild the whole underlying foundation of it from scratch making use of the new possibilities of Vue3, especially of course the composition API.

-

Nuisance

-

One nuisance I had was the way I handled state. I didn't use Vuex but instead left state handling to a global state class that I added to Vue like Vue.prototype.$store = new StorageHandler. That allowed me to access global state from everywhere within Vue components via this.$store and worked pretty well in most cases. -But when the store grew a bit more complex I wished back some of the features Vuex offers. Especially actions, name-spacing and with them the much better encapsulation of the state. It also adds extra work as soon as you need to access the state from outside Vue, for example in API call logic.

-

When moving to Vue3 I played with the thought to try Vuex4. It has the same API as Vuex3 and is meant to be usable as a drop-in when updating a Vue2 application to Vue3. But rather quickly I decided to roll my own, simplified implementation that uses the new Composition API because it would make things much neater. But lets quickly recap first what this Composition API is and how it helped me here:

-

Composition API vs Options API

-

What is the Composition API and what is the Options API? You might not have heard of those terms yet but they will become more popular within the Vue ecosystem as soon as Vue3 is out of beta.

-

The Options API is and will be the default way to build components in Vue. It is what we all know. Lets assume the following template:

-
<div>
-  <div class="greeting">{{ hello }}</div>
-  <input v-model="name" placeholder="change name" />
-
-  <div class="counter">Clicked {{ clicks }} times</div>
-  <button @click="countUp">click!</button>
-</div>
-
-

This is how an Options API example would look like:

-
const component = new Vue({
-    return {
-      name 'World',
-      clicks: 0
-    }
-  },
-  computed: {
-    hello () {
-      return `Hello ${this.name}`
-    }
-  },
-  methods: {
-    countUp () {
-      this.clicks++
-    }
-  }
-})
-
-

This still works the same in Vue3. But additionally it supports a new setup method that runs before initializing all the rest of the component and provides building blocks. Together with new imports this is the Composition API. You can use it side-by-side or exclusively to create your components. In most cased you'll not need it but as soon as you want to reuse logic or simply split a large component into logical chunks, the Composition API comes in very handy.

-

Here's one way how the example could look like using setup():

-
import { defineComponent, computed } from 'vue'
-
-// defineComponent() is now used instead of new Vue()
-const component = defineComponent({
-  setup () {
-    // greeting
-    const name = ref('World')
-    const hello = computed(() => `Hello ${name.value}`)
-    // counting
-    const clicks = ref(0)
-    const countUp = () => clicks.value++
-
-    return { name, hello, clicks, countUp }
-  }
-}  
-
-

Some things here might seem odd. computed gets imported, ref and whyname.value? Isn't that going to be annoying? It would be out of scope for this article, so I better point you to a source that explains all of this much better than I could: composition-api.vuejs.org is the place to go! There are also great courses on VueMastery.

-

Back to topic: The cool new thing now is that we can group concerns. Instead of putting each puzzle piece somewhere else (that is variables in data, reactive properties in computed and methods in methods) we can create everything grouped next to each other. What makes it even better is that thanks to the global imports, every piece can be split out into separate functions:

-
// Afraid of becoming React dev? Maybe call it 'hasGreeting' then.
-function useGreeting () {
-  const name = ref('World')
-  const hello = computed(() => `Hello ${name.value}`)
-  return { name, hello }
-}
-
-function useCounting () {
-  const count = ref(0)
-  const countUp = () => count.value = count.value + 1
-  return { count, countUp }
-}
-
-const component = defineComponent({
-  setup () {
-    const { name, hello } = useGreeting()
-    const { count: clicks, countUp } = useCounting()
-    return { name, hello, clicks, countUp }
-  }
-}  
-
-

This works the same way and it works with everything, including computed properties, watchers and hooks. It makes it also very clear where everything is coming from, unlike mixins. You can play around with this example in this Code Sandbox I made.

-

Minimalist but convenient state handling

-

While looking at the Composition API I thought about how it could be nice for simple and declarative state handling. Assuming I have somehow name-spaced state collections and actions, a bit like we know from Vuex, for example:

-
import { ref } from 'vue'
-
-// using 'ref' here because we want to return the properties directly
-// otherwise 'reactive' could be used
-export const state = {
-  name: ref('World'),
-  clicks: ref(0)
-}
-
-export const actions = {
-  'name/change': (name, newName) => {
-    name.value = newName
-  },
-  'clicks/countUp': (clicks) => {
-    clicks.value++
-  }
-}
-
-

Now this is a very simplified example of course but it should illustrate the idea. This could be used directly and the Composition API makes it not too inconvenient alread. Unfortunately it is not exactly beautiful to write (yet):

-
import { state, actions } from '@/state'
-
-defineComponent({
-  setup () {
-    return {
-      name: state.name,
-      clicks: state.clicks,
-      // brrr, not pretty
-      changeName (newName) { actions['name/change'](state.name, newName) }
-      countUp () { actions['clicks/countUp'](state.clicks) }
-    }
-  }
-})
-
-

To make this not only prettier but also less verbose, a helper can be introduced. The goal is to have something like this:

-
import { useState } from '@/state'
-
-defineComponent({
-  setup () {
-    const { collection: name, actions: nameActions } = useState('name')
-    const { collection: clicks, actions: clickActions } = useState('clicks')
-
-    return {
-      name,
-      clicks,
-      changeName: nameActions.change
-      countUp: clickActions.countUp
-    }
-  }
-})
-
-

Much nicer! And not too hard to build! Lets have a look at the useState source code:

-
function useState (prop) {
-  // assumes available state object with properties
-  // of type Ref, eg const state = { things: ref([]) }
-  const collection = state[prop]
-
-  // assumes available stateActions object with properties
-  // in the form 'things/add': function(collection, payload)
-  const actions = Object.keys(stateActions).reduce((acc, key) => {
-    if (key.startsWith(`${prop}/`)) {
-      const newKey = key.slice(prop.length + 1) // extracts action name
-      acc[newKey] = payload => stateActions[key](collection, payload)
-    }
-    return acc
-  }, {})
-
-  return { collection, actions }
-}
-
-

Just ten lines and it makes life so much easier! This returns the collection reference and maps all actions accordingly. For the sake of completeness here a full example with state and stateActions:

-
import { ref } from 'vue'
-
-// not using reactive here to be able to send properties directly
-const state = {
-  count: ref(0),
-  name: ref('World')
-}
-
-const stateActions = {
-
-  'count/increase' (countRef) {
-    countRef.value++
-  },
-  'count/decrease' (countRef) {
-    countRef.value--
-  },
-
-  'name/change' (nameRef, newName) {
-    nameRef.value = newName
-  }
-
-}
-
-function useState (prop) { /* ... */ }
-
-

Now useState('count') would return the reference state.count and an object with the actions increase and decrease:

-
import { useState } from '@/state'
-
-defineComponent({
-  setup () {
-    const { collection: count, actions: countActions } = useState('count')
-    return {
-      count,
-      countUp: countActions.increase
-    }
-  }
-})
-
-

This works well for me and happened to be very convenient already. Maybe I'll make a package out of it. What are your opinions on this?

-
-
- - - - - - diff --git a/dist/blog/index.html b/dist/blog/index.html deleted file mode 100644 index 6facb31..0000000 --- a/dist/blog/index.html +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- -

Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

-

Last updated: 2024-05-13

-
- -
- A store implementation from scratch using Vue3's Composition API - (6 to 8 minutes) -
-

- I've built a store implementation that allows name-spaced actions and helps with the separation of concerns. The new Composition API in Vue3 also allows completely new, convenient ways of using it. -

-
-
- -
- Freddy vs JSON: how to make a top-down shooter - (25 to 31 minutes) -
-

- I will tell you how I created a simple top-down shooter in JavaScript without using any additional libraries. But this article is not replicating the full game but instead tries to show which steps to take to start writing a game from scratch. -

-
-
- -
- Use OpenBSDs Spleen bitmap font in Linux - (2 to 2 minutes) -
-

- Yesterday Frederic Cambus changed the default console font in OpenBSD to his self made font [Spleen](https://github.com/fcambus/spleen) as written in this [BSD Journal article](https://undeadly.org/cgi?action=article;sid=20190110064857). -

-
-
- -
- Running writefreely 0.7 on Arm - (4 to 5 minutes) -
-

- This is a follow-up on -[The expected tutorial: How to install WriteFreely on a Raspberry pi 3 in 10 steps](https://write.as/buttpicker/the-expected-tutorial-how-to-install-writefreely-on-a-raspberry-pi-3-in-10). I will explain what was necessary to make cross-compiling work for newer WriteFreely versions with SQLite support. -

-
-
- -
- Vuejs Reactivity From Scratch - (8 to 9 minutes) -
-

- Vuejs is the star newcomer in the Javascript Framework world. People love how it makes complicated things very simple yet performant. One of the more exciting features is its seemingly magic reactivity. Plain data objects in components magically invoke a rerender when a property changes. -

-
-
- -
- The Magic 0xC2 - (3 to 4 minutes) -
-

- I built a web application with file upload functionality. Some Vue.js in the front and a CouchDB in the back. Everything should be pretty simple and straigt forward. -

But…

-

-
-
- -
- The price to crack your password - (6 to 7 minutes) -
-

- Nearly six years ago, I wrote about password complexity and showed how long it takes to crack passwords per length. You can find that [article on github](https://github.com/nkoehring/hexo-blog/blob/master/source/_posts/spas-mit-passwortern.md) (in German). -

-
-
-
- - - - - - diff --git a/dist/cv/index.html b/dist/cv/index.html deleted file mode 100644 index 5debc1d..0000000 --- a/dist/cv/index.html +++ /dev/null @@ -1,248 +0,0 @@ - - - - - - - CV/Resume // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

My Resume

-
- -

My Curriculum Vitae / Resume. I know, there is a difference. This page is technically a resume, while the whole site would be closer to a CV.

-

Last updated: 2024-05-20

-

In me you will find an enthusiastic, passionate developer with around 13 years of professional experience in and around software development, mainly full-stack web development and consulting, but also coaching and community work. I strive to seek roles in creative, forward thinking companies with diverse teams that offer challenging work, trust and responsibility. Since 2022 I'm the principal frontend engineer and frontend chapter lead of Code Gaia.

-

Principal Frontend Engineer, Code Gaia

-
-

Gode Gaia GmbH, Munich / remote (since August 2022)

-
-

Main responsibilities

- -

Key Technologies

- -

Noteworthy aspects

- -
-

Senior Software Engineer, Coursedog

-
-

Coursedog Inc, New York / remote (June 2021 till June 2022)

-
-

Main responsibilities

- -

Key Technologies

- -

Noteworthy aspects

- -
-

Senior Consultant, Wunderdog

-
-

Wunderdog GmbH, Helsinki / Berlin / remote (June 2018 till June 2021)

-
-

Main responsibilities

- -

Key Technologies

- -

Noteworthy aspects

- -
-

Senior Software Engineer, HERE

-
-

HERE Global BV, Berlin (November 2017 till March 2018)

-
-

Main responsibilities

- -

Key Technologies

- -
-

Senior Software Engineer, FromAtoB

-
-

FromAtoB GmbH, Berlin (August 2016 till September 2017)

-
-

Main responsibilities

- -

Key Technologies

- -
-

Software Engineer (freelancing)

-
-

Berlin, remote (June 2015 till August 2017)

-
-

Clients (selection)

- -

Key Technologies

- -
-

Software Engineer, HERE

-
-

HERE Global BV, Berlin (November 2013 till May 2015)

-
-

Main responsibilities

- -

Key Technologies

- -
-

Software Engineer (freelancing)

-
-

Leipzig, Berlin, remote (October 2009 till October 2013)

-
-

Clients (selection)

- -

Key Technologies

- -
-
- - - - - - diff --git a/dist/extended.css b/dist/extended.css deleted file mode 100644 index b8730b4..0000000 --- a/dist/extended.css +++ /dev/null @@ -1,46 +0,0 @@ -#main-menu { - position: fixed; - top: var(--header-height); - width: 100vw; - background-color: var(--menu-bg-color); - transition: top .3s ease-in-out, background-color 1s ease-in; -} - -#main-menu>menu { - width: 960px; - max-width: 98%; - height: 1.2rem; - margin: 0 auto 0; - padding: 0; - display: flex; - justify-content: space-around; - align-items: center; - list-style: circle; -} -#main-menu > li { - padding: 0; -} -body>header.small + #main-menu { - top: var(--header-height-small); - background-color: var(--header-bg-color); -} -body>header.small + #main-menu>menu { - padding: .5rem 0; -} -pre { - background: var(--emboss-color); - padding: .5rem; -} -li.active>a { - color: var(--highlight-fg-color); - font-weight: bold; -} - -@media (max-width: 480px) { - #main-menu>menu { - height: 2.4rem; - margin-left: 1.5rem; - flex-flow: column wrap; - align-items: flex-start; - } -} diff --git a/dist/index.html b/dist/index.html deleted file mode 100644 index db64327..0000000 --- a/dist/index.html +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - Norman Köhring // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

- Hi there! I am a - programmer, - open-source - enthusiast - and - hacker - based in Berlin, Germany. -

-

- I call myself a code artist, because programming can and should be seen as a creative process; therefore code is - art. I love to craft pieces of art with code, that are beautiful and elegant in their simplicity, readability - and architecture. -

-

- Looking for expert advice and development services for a short-term project? I offer guidance on software - architecture decisions, coding solutions and performance optimizations tailored to your needs. Let's work - together to solve your challenges. - Get in touch! -

- - -
-
-

experience

-
-

Thirteen years of professional experience in a couple of tweets

-
-

Pretty early in my life I realized that I work best on my own terms. That does not mean that I prefer to work alone. Working with clients, team mates, designers and managers is a crucial part of any development process.

-

Some time in the year 2009 I decided to not only live up to my way of working but also share my experience even more. I decided to become a freelancing programmer and consultant. Since then many different places benefited from my work. Start-Ups in their first months as well as well known companies like HERE and Deutsche Telekom Labs.

-

Together with entrepreneurs, UI/UX experts and engineers of many fields I created novel and beautiful applications that still influence the live of thousands of people.

-

Please see my CV for a more detailed list.

-

coaching

-
-

Whenever possible, I try to help others to learn

-
-

I’m the organizer of Vuejs // Berlin, a monthly meetup group around Vue and web technologies in general.

-

Many people want to learn and grow. Whenever I can I try to help those people by sharing my experience and knowledge. I already voluntarily coached at Code Curious, Frauenloop and Jugend Hackt. I also helped children with their first steps into the world of programming at the Berlin CoderDojo.

-

contact

-
-

You can find me all over the interwebs

-
- -
- -
-
- - - - - - - - diff --git a/dist/now/index.html b/dist/now/index.html deleted file mode 100644 index 061e3fa..0000000 --- a/dist/now/index.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - - /now // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Now -- What I'm up to right now

-
- -

This page shows what I'm up to at the moment, following the idea of the /now page introduced by Derek Sivers. You can find more now pages on nownownow.

-

Last updated: 2024-05-12

-

Still live in Berlin where I am working fully remote. I'm appproaching the second anniversary at Code Gaia now and have no plans to change any of it.

-

Priorities

-
-

I do a lot of things all the time and have a hard time to focus. Most of my energy right now hopefully flows into the following things:

-
- -

Book(s)

-
-

I'm not really good with taking time for reading, but when I do, I read:

-
-

Accelerando -by Charles Stross

-

The Manager's Path -by Camille Fournier

-
-
- - - - - - diff --git a/dist/projects/index.html b/dist/projects/index.html deleted file mode 100644 index 2f94165..0000000 --- a/dist/projects/index.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - Active Projects // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Active Projects

-
- -

My currently active projects. This is mostly about software, but might also include some TTRPG stuff, from time to time.

-

Last updated: 2024-05-17

-

Homepage Overhaul

-
-

With lots of work comes lots of opportunity for productive procrastination

-
-

Not too long ago, .ing TLDs became available, that allowed me to finally have my full name as a "cool" domain name: koehr.ing. Other domains I have are nkoehring.de (boring), koehr.in (confusing) and k0r.in (nerdy). koehri.ng wouldn't be possible due to domain registars policies or pricing (Nigeria used to have the british model, like allowing only net.ng, com.ng, and so on. Later they allowed more, but the price would be pretty high).

-

Why am I writing all this? Because the new domain name made me think about my homepage as a professional. I wanted to have something, that showcases my skills while not being the usual boring homepage. This is how the interactive homepage experiment began; a terminal like website, written from scratch. Having this, I now also needed to change my old homepage to somehow feature my new shiny experiment. But my old homepage is white and not very responsive; two very good reasons (for me), to change it. So I also started writing a completely new homepage, using vss. Pretty soon I realised, it is by far not mature enough for my needs, so I started building workarounds to suit my needs, so I don't get stuck in the rabbit hole of choosing frameworks over finishing the page. My plan is, to finish the page and its content and then, when there is time, move it on top of something more sophisticated, like good ol' Zola.

-

New Server

-

I found a pretty cheap dedicated server with tons of space and quite some CPU power, compared to cheap virtual servers. Now I need to move everything I hosted on a VServer before. That is not a simple task, unfortunately, as I tend to overthink and want to use the change to make everything better (or just different, maybe). This move includes a switch from Docker and systemd services to podman and lingering users. This way, no root enabled service is involved in running any outside-facing services. This website and everything under the koehr.ing domain runs already on the new server.

-

learned.today

-

Quite a while (aka way too long) ago, I bought the domain learned.today and thought about some idea around a Today I learned page or service, where people just share short snippets of things they just learned, similar to my TIL page. I never got to implementing it though. I wrote it down here as a motivation for myself, to finally work on it.

-
-
- - - - - - diff --git a/dist/setup/index.html b/dist/setup/index.html deleted file mode 100644 index f6860c0..0000000 --- a/dist/setup/index.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - - My Setup // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

My Hardware Setup

-
- -

As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use. This page focusses on Hardware. For Software, check /stack.

-

Last updated: 2024-05-20

-

I used to work on laptops without any extras, but over the years ergonomics got more and more important. Now I have a second screen, a standing desk and an ergonomic chair. My main keyboard is split in half and my pointer device is a big red ball.

-

Work Computer: Thinkpad T14s

-
-

Decent CPU, good amount of RAM, very lightweight, great battery life

-
-

Thinkpads are my go-to laptops for work. They are robust and performant.

-

Private Computer: ASUS Zenbook Pro Duo

-
-

Fantastic screen, a second display, decent hardware

-
-

My private laptop is a bit more experimental. It features a dual screen setup with a 16:10 OLED screen and an additional 16:5(-ish) LCD above the keyboard.

-

Keyboard: Sofle 2 split-keyboard

-

I use the Sofle 2 keyboard. I adapted it to my needs. It features two rotary encoders and a customized qmk firmware configuration. The source code can be found on github.

-

Pointer: Kensington Orbit

-

The Kensington Orbit is a trackball and a treat for every wrist.

-

Desk: ergonomic

-

My desk is height adjustable, so that I can sit or stand at it. Its not a fancy branded one; it does it job well, though.

-

Chair: ergonomic

-

My chair is an ergonomic office chair with 4D arm rests and extra back support. I can sit on it all day without issues.

-
-
- - - - - - diff --git a/dist/stack/index.html b/dist/stack/index.html deleted file mode 100644 index c424e9e..0000000 --- a/dist/stack/index.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - My Stack // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

My Software Stack

-
- -

As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use. This page focusses on Software. For Hardware, check /setup.

-

Last updated: 2024-05-13

-

My software stack is pretty old-school. I prefer CLI applications for almost everything. The only GUI programs I usually run are browsers, image manipulators and LogSeq.

-

OS: Fedora Linux

-

It all started with Real Red Linux 2000, a special millenium version of RedHat Linux. I don't know for sure, but I think it was based on RedHat 6.1 or 6.2.

-

Over the years, I first used different RPM based distributions, then switched to Gentoo for a while, before getting annoyed by the compiling frenzy and discovering Arch. When Arch made the switch to systemd, I found Void Linux and stayed with it for years. At some point, not many years ago, I went with Fedora and it struck a nice middle ground between customizability and "it just works". Thanks to Fedora Spins, it is now easy to have a more standard system on my work laptop and a rather customized one on my private laptop, without too many differences in the foundation. I use official the Sway Spin on my private laptop.

-

DE: GNOME vs Sway

-

Over the years I got used to tiling window managers. Honestly, I tried almost all of them and went from hyper-configurable to super minimalist. I ended up - as usual - somewhere in the middle, with i3 and Sway.

-

My work laptop has a GNOME desktop with some extensions, that make it work well for me. My typical work flow involves full screen applications and many desktops. I rarely have more than one window on one screen. That is why I didn't have too much of a hard time to switch from dwm and similar tiling window managers to GNOME, because it uses MacOS-like gestures to work with desktops. Extensions like Maximize Lonely Window help as well. There used to be another extension, Maximize To Empty Workspace, which was even closer to my usual way of working. But it is not supported in newer GNOME versions.

-

Editor: Helix

-

Most of my life, I used ViM. It made me more productive and helped me to focus on the things that matter most for my productivity. One day, I found Kakoune, which blew me away by being so similar and yet different to ViM, in a (in my opinion) good way. What Kakoune does is to to switch around the command order. While ViM's command language is VERB-MODIFIER-OBJECT. For example: d2w means delete two words. Kakoune switches that to MODIFIER-VERB-OBJECT and introduces selecting and non-selecting movement, which allows you to see your selection before applying an action. d2w changes to 2Wd, which translates to select next two words, then delete them. I finally settled with Helix, an editor that uses Kakounes command language, but implements many useful things by default, while still being very configurable.

-

Terminal: foot + zellij + zsh

-

Almost all of my day-to-day applications are in the terminal. I am so used to it, that I started trusting GUI applications less. This is obviously my issue, but luckily I'm not alone, so many great CLI applications exist.

-

I use foot as terminal emulator. It is lightweight, supports 24bit colours and works with Wayland.

-

Inside foot runs zellij, which is a terminal multiplexer similar to screen and tmux. It allows me to run multiple applications in one terminal, keeps sessions alive after closing the terminal emulator and so on. I actually configured zellij to feel a lot more like tmux, because I'm so used to the latter and honestly I might just switch back to tmux, who knows.

-

My shell of choice is zsh with oh-my-zsh. It is by far the most versatile shell and the only one (to my knowledge) that supports RPROMPT, a prompts at the end of the line.

-

Browser: Firefox

-

My browser of choice is Firefox, because I want an open and diverse internet. Firefox is a great choice and offers lots of features, like direct PDF support, privacy features out of the box and great synchronisation. Chrome and Chromium-based browsers are great as well, but if everyone uses the same browser, we'll end up with whatever the company behind this browser wants the internet to be.

-

Other Tools: LogSeq, Poe, Bitwarden, Git...

-

Of course, I use a lot more tools in my day-to-day work.

-

I use LogSeq for knowledge management. It is similar to Evernote, Obsidian or Notion. For me it hits the mark between flexibility and structure. I use it for everthing from todo lists to planning long D&D campaigns.

-

Poe allows access to all kinds of generative intelligence tools, like LLMs ("ChatGPT") and image generators. I mostly use Mistral, but also switch between models from time to time. They help me with brainstorming and sometimes I misuse them to write JSDoc comments for me.

-

Bitwarden is a fantastic password manager with lots of utilities. It works so that you don't need to trust the server provider, because everything runs on the client (for example in a browser plugin) and is encrypted locally before being sent to the server. The best thing is, that I can host a bitwarden server myself, using Vaultwarden.

-

GIT is the most widely used source code management as of today. Although I see some strengths in other systems, Git is by far good enough for all my needs. I host my own Forgejo git server at git.k0r.in.

-

There is a lot more and I might extend this list from time to time.

-
-
- - - - - - diff --git a/dist/til/2021-08-31.html b/dist/til/2021-08-31.html deleted file mode 100644 index d74e269..0000000 --- a/dist/til/2021-08-31.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

There is a HTML tag for "Word Break Opportunity"

-

source

-

For example: Kauf<wbr/>haus.

-
-
- - - - - - diff --git a/dist/til/2021-09-03.html b/dist/til/2021-09-03.html deleted file mode 100644 index 8c28da1..0000000 --- a/dist/til/2021-09-03.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Bush refused offer to discuss Osama Bin Laden handover

-

source

-
-
- - - - - - diff --git a/dist/til/2021-09-04.html b/dist/til/2021-09-04.html deleted file mode 100644 index c8a8359..0000000 --- a/dist/til/2021-09-04.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

git fetch $repo_url $remote_branch:$new_local_branch

-

source

-
-
- - - - - - diff --git a/dist/til/2021-09-05.html b/dist/til/2021-09-05.html deleted file mode 100644 index 0b85c88..0000000 --- a/dist/til/2021-09-05.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

E-Mail that isn't spam is called ham!

-

source

-
-
- - - - - - diff --git a/dist/til/2022-02-22.html b/dist/til/2022-02-22.html deleted file mode 100644 index b1deec0..0000000 --- a/dist/til/2022-02-22.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Adding aliases in vite with typescript needs the same alias in tsconfig

-

For example:

-

The following vite.config.ts:

-
import { fileURLToPath, URL } from "url"
-import { defineConfig } from 'vite'
-import vue from '@vitejs/plugin-vue'
-
-// https://vitejs.dev/config/
-export default defineConfig({
-  plugins: [vue()],
-  resolve: {
-    alias: {
-      "~": fileURLToPath(new URL("./src", import.meta.url)),
-      "~component": fileURLToPath(new URL("./src/components", import.meta.url)),
-      "~composable": fileURLToPath(new URL("./src/composables", import.meta.url)),
-      "~lib": fileURLToPath(new URL("./src/lib", import.meta.url)),
-    }
-  }
-})
-
-

will need this in tsconfig.json:

-
{
-  "compilerOptions": {
-    "paths": {
-      "~/*": [ "./src/*" ],
-      "~component/*": [ "./src/components/*" ],
-      "~composable/*": [ "./src/composables/*" ],
-      "~lib/*": [ "./src/lib/*" ]
-    }
-  }
-}
-
-

The asterixes in the syntax are important (alias/* => ./path/*).

-
-
- - - - - - diff --git a/dist/til/2022-03-22.html b/dist/til/2022-03-22.html deleted file mode 100644 index cde8994..0000000 --- a/dist/til/2022-03-22.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

There is a file system for EFI vars now

-

source

-

On kernel updates I saw a recurring "EFI variables are not supported on this system", so I investigated and learned that the new EFI variables are provided via a file system that needs to be mounted first:

-
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
-
-
-
- - - - - - diff --git a/dist/til/2022-03-28.html b/dist/til/2022-03-28.html deleted file mode 100644 index f0a3bed..0000000 --- a/dist/til/2022-03-28.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

pwdx command shows the working path of a process

-

source

-

For example:

-
% pwdx 1984
-> 1984: /home/george/ttlctrl
-
-
-
- - - - - - diff --git a/dist/til/2022-04-25.html b/dist/til/2022-04-25.html deleted file mode 100644 index 8cd7bf3..0000000 --- a/dist/til/2022-04-25.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Jest mocks are ...different

-

If you want to mock an imported function in Jest in a way that allows you to check if it has been called, you can not do the seemingly straighforward:

-
// mock prefix necessary btw
-const mockThatFunction = jest.fn(() => 'stuff')
-
-jest.mock('@/path/to/module', () => ({
-  thatFunction: mockThatFunction,
-}))
-
-// ...in test descriptions
-expect(mockThatFunction).toHaveBeenCalled()
-
-

This way thatFunction will be undefined without anyone telling you why.

-

What you need to do instead:

-
import { thatFunction } from '@/path/to/module'
-
-jest.mock('@/path/to/module', () => ({
-  thatFunction: jest.fn(() => 'stuff'),
-}))
-
-// ...in test descriptions
-expect(thatFunction).toHaveBeenCalled()
-
-
-
- - - - - - diff --git a/dist/til/2022-06-15.html b/dist/til/2022-06-15.html deleted file mode 100644 index 6bf0d25..0000000 --- a/dist/til/2022-06-15.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Disallowed Focussed Tests and how it saved my day

-

Today I was about to push a focussed test. A focussed test, you ask?

-

In Jest (and others) one can run only a specific test, by writing it.only(.... Pushing this to production might create some funny or not so funny side effects though. Luckily there is the no-focussed-tests linter rule in eslint-plugin-jest.

-
-
- - - - - - diff --git a/dist/til/2024-05-11.html b/dist/til/2024-05-11.html deleted file mode 100644 index 99d264c..0000000 --- a/dist/til/2024-05-11.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Rob Pike's 5 Rules of Programming

-

source

-
    -
  1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
    2. -
  2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
    3. -
  3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
    4. -
  4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
    5. -
  5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
    6. -
-

Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Ken Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.". Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".

-
-
- - - - - - diff --git a/dist/til/2024-05-12.html b/dist/til/2024-05-12.html deleted file mode 100644 index 53044da..0000000 --- a/dist/til/2024-05-12.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Sort list of strings in Javascript

-

source

-
users.sort((a, b) => a.firstname.localeCompare(b.firstname))
-
-

or reversed order:

-
users.sort((a, b) => a.firstname.localeCompare(b.firstname) * -1)
-
-
-
- - - - - - diff --git a/dist/til/2024-05-13.html b/dist/til/2024-05-13.html deleted file mode 100644 index 03dab57..0000000 --- a/dist/til/2024-05-13.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

Reading speed is usually from 100 to 260 words per minute

-

source

-

With an average of 183 wpm.

-
-
- - - - - - diff --git a/dist/til/index.html b/dist/til/index.html deleted file mode 100644 index 979b01f..0000000 --- a/dist/til/index.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- -

This page contains short notes and sometimes code snippets, of interesting things I just found out.

-

Last updated: 2024-05-13

-
- -
- Reading speed is usually from 100 to 260 words per minute - (source) -
-
-
- -
- Sort list of strings in Javascript - (source) -
-
-
- -
- Rob Pike's 5 Rules of Programming - (source) -
-
-
- -
- Disallowed Focussed Tests and how it saved my day - (source) -
-
-
- -
- Jest mocks are ...different - (source) -
-
-
- -
- pwdx command shows the working path of a process - (source) -
-
-
- -
- There is a file system for EFI vars now - (source) -
-
-
- -
- Adding aliases in vite with typescript needs the same alias in tsconfig - (source) -
-
-
- -
- E-Mail that isn't spam is called ham! - (source) -
-
-
- -
- it fetch $repo_url $remote_branch:$new_local_branch` - (source) -
-
-
- -
- Bush refused offer to discuss Osama Bin Laden handover - (source) -
-
-
- -
- There is a HTML tag for "Word Break Opportunity" - (source) -
-
-
-
- - - - - - diff --git a/layouts/blog.html b/layouts/blog.html new file mode 100644 index 0000000..2f74610 --- /dev/null +++ b/layouts/blog.html @@ -0,0 +1,34 @@ + + + + + + + +
+
+

+ +
+ +
+ +
    +
  1. + +
    + + (~ mins) +
    +

    +
    2. +
+
+ + diff --git a/layouts/blog/index.html b/layouts/blog/index.html deleted file mode 100644 index d106242..0000000 --- a/layouts/blog/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - Weblog aka Blog // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Weblog

-
- - @contents -
-
- - - - - - diff --git a/layouts/cv/index.html b/layouts/cv/index.html deleted file mode 100644 index 84e078f..0000000 --- a/layouts/cv/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - CV/Resume // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

My Resume

-
- - @contents -
-
- - - - - - diff --git a/layouts/homepage.html b/layouts/homepage.html new file mode 100644 index 0000000..dcfc13a --- /dev/null +++ b/layouts/homepage.html @@ -0,0 +1,58 @@ + + + + + +
+
+

+ Hi there! I am a + programmer, + open-source + enthusiast + and + hacker + based in Berlin, Germany. +

+

+ I call myself a code artist, because programming can and should be seen as a creative process; therefore code is + art. I love to craft pieces of art with code, that are beautiful and elegant in their simplicity, readability + and architecture. +

+

+ Looking for expert advice and development services for a short-term project? I offer guidance on software + architecture decisions, coding solutions and performance optimizations tailored to your needs. Let's work + together to solve your challenges. + Get in touch! +

+ + +
+ +
+ + +
+ +
+
diff --git a/layouts/index.html b/layouts/index.html deleted file mode 100644 index c8b25e6..0000000 --- a/layouts/index.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - - @title // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

- Hi there! I am a - programmer, - open-source - enthusiast - and - hacker - based in Berlin, Germany. -

-

- I call myself a code artist, because programming can and should be seen as a creative process; therefore code is - art. I love to craft pieces of art with code, that are beautiful and elegant in their simplicity, readability - and architecture. -

-

- Looking for expert advice and development services for a short-term project? I offer guidance on software - architecture decisions, coding solutions and performance optimizations tailored to your needs. Let's work - together to solve your challenges. - Get in touch! -

- - -
-
- @contents -
- -
-
- - - - - - - - diff --git a/layouts/now/index.html b/layouts/now/index.html deleted file mode 100644 index c1e1477..0000000 --- a/layouts/now/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - /now // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Now -- What I'm up to right now

-
- - @contents -
-
- - - - - - diff --git a/layouts/page.html b/layouts/page.html new file mode 100644 index 0000000..4e89e65 --- /dev/null +++ b/layouts/page.html @@ -0,0 +1,17 @@ + + + + + +
+
+

+ +
+ Last updated: +
+ +
+
+ +
diff --git a/layouts/projects/index.html b/layouts/projects/index.html deleted file mode 100644 index cb64d86..0000000 --- a/layouts/projects/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - Active Projects // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

Active Projects

-
- - @contents -
-
- - - - - - diff --git a/layouts/setup/index.html b/layouts/setup/index.html deleted file mode 100644 index cf7b8c9..0000000 --- a/layouts/setup/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - My Setup // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

My Hardware Setup

-
- - @contents -
-
- - - - - - diff --git a/layouts/stack/index.html b/layouts/stack/index.html deleted file mode 100644 index 7582eec..0000000 --- a/layouts/stack/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - My Stack // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

My Software Stack

-
- - @contents -
-
- - - - - - diff --git a/layouts/templates/base.html b/layouts/templates/base.html new file mode 100644 index 0000000..6cd59a3 --- /dev/null +++ b/layouts/templates/base.html @@ -0,0 +1,105 @@ + + + + + + <super/> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/layouts/til.html b/layouts/til.html new file mode 100644 index 0000000..3a578e2 --- /dev/null +++ b/layouts/til.html @@ -0,0 +1,34 @@ + + + + + + + +
+
+

+ +
+ Last updated: +
+ +
+ +
    +
  1. + +
    + + (source) +
    +
    2. +
+
+ +
diff --git a/layouts/til/index.html b/layouts/til/index.html deleted file mode 100644 index 620b893..0000000 --- a/layouts/til/index.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - Today I learned // the codeartist — programmer and engineer based in Berlin - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-

TIL -- Today I learned

-
- - @contents -
-
- - - - - - diff --git a/static/extended.css b/static/extended.css deleted file mode 100644 index b8730b4..0000000 --- a/static/extended.css +++ /dev/null @@ -1,46 +0,0 @@ -#main-menu { - position: fixed; - top: var(--header-height); - width: 100vw; - background-color: var(--menu-bg-color); - transition: top .3s ease-in-out, background-color 1s ease-in; -} - -#main-menu>menu { - width: 960px; - max-width: 98%; - height: 1.2rem; - margin: 0 auto 0; - padding: 0; - display: flex; - justify-content: space-around; - align-items: center; - list-style: circle; -} -#main-menu > li { - padding: 0; -} -body>header.small + #main-menu { - top: var(--header-height-small); - background-color: var(--header-bg-color); -} -body>header.small + #main-menu>menu { - padding: .5rem 0; -} -pre { - background: var(--emboss-color); - padding: .5rem; -} -li.active>a { - color: var(--highlight-fg-color); - font-weight: bold; -} - -@media (max-width: 480px) { - #main-menu>menu { - height: 2.4rem; - margin-left: 1.5rem; - flex-flow: column wrap; - align-items: flex-start; - } -} diff --git a/static/posts.css b/static/posts.css index 135b44c..e8186a0 100644 --- a/static/posts.css +++ b/static/posts.css @@ -1,7 +1,3 @@ -main.posts { - margin: calc(var(--header-height-small) + 4rem) auto 4rem; -} - main.posts h2 { margin: 1.5em 0 0 0; font-size: 1.5rem; @@ -25,16 +21,3 @@ main.posts article>div>a.external, main.posts article>div>.reading-time { color: gray; } - -hr { - display: block; - border: none; - width: 100%; - height: 1px; - margin: 2rem 0; - background-color: var(--emboss-color); -} - -span[title] { - text-decoration: underline wavy gray; -} \ No newline at end of file diff --git a/static/style.css b/static/style.css index 5c5d9e1..d51167c 100644 --- a/static/style.css +++ b/static/style.css @@ -53,6 +53,44 @@ body { scroll-behavior: smooth; } +#main-menu { + position: fixed; + top: var(--header-height); + width: 100vw; + background-color: var(--menu-bg-color); + transition: top .3s ease-in-out, background-color 1s ease-in; +} + +#main-menu>menu { + width: 960px; + max-width: 98%; + height: 1.2rem; + margin: 0 auto 0; + padding: 0; + display: flex; + justify-content: space-around; + align-items: center; + list-style: circle; +} +#main-menu > li { + padding: 0; +} +body>header.small + #main-menu { + top: var(--header-height-small); + background-color: var(--header-bg-color); +} +body>header.small + #main-menu>menu { + padding: .5rem 0; +} +pre { + background: var(--emboss-color); + padding: .5rem; +} +li.active>a { + color: var(--highlight-fg-color); + font-weight: bold; +} + body>#spacer, body>header { position: fixed; @@ -66,7 +104,7 @@ body>#spacer { height: var(--header-height-small); } -body>header { +body>header, body>header>a { height: var(--header-height); color: transparent; transition: transform .3s ease-in-out; @@ -77,7 +115,7 @@ body>header.small { transform: scale(var(--header-height-multiplier)); } -body>header>svg { +body>header svg { display: block; width: 960px; max-width: 98vw; @@ -91,6 +129,11 @@ body>main { margin: var(--header-height) auto 4rem; } +body>main>header { + display: block; + padding: 2em 0; +} + a { color: var(--page-fg-color); } @@ -117,7 +160,7 @@ code { padding-top: 2rem; } #content>h1, -main.posts > header > h1 { +main > header > h1 { margin: 0 0 .25em; font-size: 2rem; font-variant: small-caps; @@ -127,6 +170,9 @@ main.posts > header > h1 { #content>h1 { padding-top: 2em; } +h2 { + color: var(--highlight-fg-color); +} #cta { display: flex; @@ -203,6 +249,19 @@ main.posts > header > h1 { animation: fade 2s linear infinite; } +hr { + display: block; + border: none; + width: 100%; + height: 1px; + margin: 2rem 0; + background-color: var(--emboss-color); +} + +span[title] { + text-decoration: underline wavy gray; +} + @keyframes fade { 0% { opacity: 1.0; @@ -239,6 +298,25 @@ main.posts > header > h1 { } @media (max-width: 480px) { + body>header.small { + transform: none; + } + body>header.small + #main-menu { + top: var(--header-height); + } + #main-menu>menu { + height: 2.4rem; + margin-left: 1.5rem; + padding: .5rem 0; + flex-flow: column wrap; + align-items: flex-start; + } + body>main { + margin: calc(var(--header-height) + 2rem) auto 4rem; + } + #content > h1 { + padding-top: calc(var(--header-height) + 2rem); + } .contacts { columns: 1; } diff --git a/til/2021-08-31.md b/til/2021-08-31.md deleted file mode 100644 index 2c775fd..0000000 --- a/til/2021-08-31.md +++ /dev/null @@ -1,5 +0,0 @@ -# There is a HTML tag for "Word Break Opportunity" - -[source](https://www.w3schools.com/TAGS/tag_wbr.asp) - -For example: `Kaufhaus`. diff --git a/til/2021-09-03.md b/til/2021-09-03.md deleted file mode 100644 index 9008aef..0000000 --- a/til/2021-09-03.md +++ /dev/null @@ -1,3 +0,0 @@ -# Bush refused offer to discuss Osama Bin Laden handover - -[source](https://www.theguardian.com/world/2001/oct/14/afghanistan.terrorism5) diff --git a/til/2021-09-04.md b/til/2021-09-04.md deleted file mode 100644 index f775578..0000000 --- a/til/2021-09-04.md +++ /dev/null @@ -1,3 +0,0 @@ -`git fetch $repo_url $remote_branch:$new_local_branch` - -[source](https://twitter.com/lucas59356/status/1433507127570669569) diff --git a/til/2021-09-05.md b/til/2021-09-05.md deleted file mode 100644 index d0413dd..0000000 --- a/til/2021-09-05.md +++ /dev/null @@ -1,3 +0,0 @@ -# E-Mail that isn't spam is called ham! - -[source](https://twitter.com/claranellist/status/1433539284779220997) diff --git a/til/2022-03-22.md b/til/2022-03-22.md deleted file mode 100644 index 5131e51..0000000 --- a/til/2022-03-22.md +++ /dev/null @@ -1,9 +0,0 @@ -# There is a file system for EFI vars now - -[source](https://www.kernel.org/doc/html/latest/filesystems/efivarfs.html) - -On kernel updates I saw a recurring "EFI variables are not supported on this system", so I investigated and learned that the new EFI variables are provided via a file system that needs to be mounted first: - -```sh -mount -t efivarfs efivarfs /sys/firmware/efi/efivars -``` diff --git a/til/2022-03-28.md b/til/2022-03-28.md deleted file mode 100644 index aac9716..0000000 --- a/til/2022-03-28.md +++ /dev/null @@ -1,10 +0,0 @@ -# pwdx command shows the working path of a process - -[source](https://twitter.com/mani_maranp/status/1508476973529825281) - -For example: - -```sh -% pwdx 1984 -> 1984: /home/george/ttlctrl -``` diff --git a/til/2024-05-12.md b/til/2024-05-12.md deleted file mode 100644 index 37de2c8..0000000 --- a/til/2024-05-12.md +++ /dev/null @@ -1,13 +0,0 @@ -# Sort list of strings in Javascript - -[source](https://stackoverflow.com/questions/6712034/sort-array-by-firstname-alphabetically-in-javascript) - -```ts -users.sort((a, b) => a.firstname.localeCompare(b.firstname)) -``` - -or reversed order: - -```ts -users.sort((a, b) => a.firstname.localeCompare(b.firstname) * -1) -``` diff --git a/til/2024-05-13.md b/til/2024-05-13.md deleted file mode 100644 index b1ef36f..0000000 --- a/til/2024-05-13.md +++ /dev/null @@ -1,5 +0,0 @@ -# Reading speed is usually from 100 to 260 words per minute - -[source](https://thereadtime.com/) - -With an average of 183 wpm. diff --git a/til/index.md b/til/index.md deleted file mode 100644 index eb86a6a..0000000 --- a/til/index.md +++ /dev/null @@ -1,99 +0,0 @@ -*This page contains short notes and sometimes code snippets, of interesting things I just found out.* - -Last updated: 2024-05-13 - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/zig-out/blog/2016-12-04-the-price-to-crack-your-password/index.html b/zig-out/blog/2016-12-04-the-price-to-crack-your-password/index.html new file mode 100644 index 0000000..06020bd --- /dev/null +++ b/zig-out/blog/2016-12-04-the-price-to-crack-your-password/index.html @@ -0,0 +1,159 @@ + + + + + + the codeartist — programmer and engineer based in BerlinThe price to crack your password + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

The price to crack your password

+ Nearly six years ago, I wrote about password complexity and showed how long it takes to crack passwords per length. +
+ Last updated: +
+ +

You can find the original article on github (in German).

So, times changed and I thought about a reiteration of that topic, but instead focussing on the amount of money you need to crack the password using Amazons biggest GPU computing instances p2.16xlarge, which – at the time of writing this - costs 14.4 USD per hour. I will also compare this with the much faster Sagitta Brutalis (nice name, eh?), a 18500 USD computer optimised for GPU calculation.

Disclaimer

The numbers on this article always assume brute-force attacks, that means the attacker uses a program that tries all possible combinations until it finds the password. The numbers indicate average time to compute all possible entries. If the program simply adds up, for example, from 000000 to 999999 and your password is 000001, it will be found much faster of course.

How long a single calculation needs also depends on the used hashing algorithm. I will compare some of the typically used algorithms. In case you have to implement a password security system, please use BCrypt which is in most cases the best choice but NEVER try to implement something on your own! It is never ever a good idea to create an own password hashing scheme, even if it is just assembled out of existing building blocks. Use the battle-tested standard solutions. They are peer-reviewed and the safest and most robust you can get.

Password complexity basics

Password complexity is calculated out of the possible number of combinations. So a 10-character password that only contains numbers is far less complex than a mix of letters and numbers of the same length. Usually an attacker has no idea if a specific password only contains numbers or letters, but a brute-force attack will try simpler combinations first.

To calculate the complexity of a password, find the amount of possible combinations first:

  • Numbers: 10

  • ASCII Lowercase letters: 26

  • ASCII Uppercase letters: 26

  • ASCII Punctuation: 33

  • Other ASCII Characters: 128

  • Unicode: millions

To get the complexity of your password, simply add up the numbers. A typical password contains numbers, lowercase and uppercase letters which results in 62 possible combinations per character. Add some punctuation to raise that number to 95.

Other ASCII Characters are the less typical ones like ÿ and Ø which add to the complexity but might be hard to type on foreign keyboards. Unicode is super hard (if not impossible) to type on some computers but would theoretically add millions of possible characters. Fancy some ਪੰਜਾਬੀ ਦੇ in your password?

A very important factor in the password complexity is of course also the length. And because random passwords with crazy combinations of numbers, letters and punctuation are hard to remember, some people suggest to use long combination of normal words instead.

The password ke1r$u@U is considered a very secure password as the time of writing this article. Its complexity calculates like this:

8 characters with 95 possibilites:

95^8 = 6634204312890625 = ~6.6×10^15

log2(x) calculates the complexity in bits:

log2(6634204312890625) = ~52.56 bits

Data sources

I didn't try the password cracking myself, and neither did I ask a friend (insert trollface here). Instead I used publicly available benchmark results:

The results

I will compare some widely used password hashing methods, programs and protocols for four different password complexity categories:

  • eight numeric digits (might be your birthday)

  • eight alphanumeric characters (eg 'pa55W0Rd')

  • eigth alphanumeric characters mixed with special character (eg 'pa$$W0Rd')

  • a long memorisable pass sentence ('correct horse battery staple')

eight numeric digits (might be your birthday)

+ + + + + + + + +
hashAmazonBrutalisprice to crack in less than a month
+
      MD5 |    0.0s |     0.0s | $0.01 (1 EC2 instance)
+    Skype |    0.0s |     0.0s | $0.01 (1 EC2 instance)
+     WPA2 |   1.27m |   31.47s | $0.30 (1 EC2 instance)
+   SHA256 |   0.01s |     0.0s | $0.01 (1 EC2 instance)
+   BCrypt |   49.1m |   15.77m | $11.78 (1 EC2 instance)
+

AndroidPIN | 4.65s | 2.3s | $0.02 (1 EC2 instance) MyWallet | 0.34s | 0.25s | $0.01 (1 EC2 instance) BitcoinWallet | 1.98h | 46.26m | $28.53 (1 EC2 instance) LastPass | 11.07s | 5.4s | $0.04 (1 EC2 instance) TrueCrypt | 9.06m | 5.69m | $2.18 (1 EC2 instance) VeraCrypt | 4d | 2d | $1120.45 (1 EC2 instance)

Conclusion: Don't do this. Never ever do this.

eight alphanumeric characters (eg 'pa55W0Rd')

+ + + + + + + + +
hashAmazonBrutalisprice to crack in less than a month
+
      MD5 |  49.65m |   18.17m | $11.92 (1 EC2 instance)
+    Skype |    1.3h |   34.92m | $18.67 (1 EC2 instance)
+     WPA2 |      6y |       3y | $499500 (27 Brutalis)
+   SHA256 |   4.94h |    2.64h | $71.15 (1 EC2 instance)
+   BCrypt |    204y |      66y | $14.7M (797 Brutalis)
+

AndroidPIN | 118d | 59d | $37000 (2 Brutalis) MyWallet | 9d | 7d | $3003.3 (1 EC2 instance) BitcoinWallet | 494y | 193y | $43.25M (2338 Brutalis) LastPass | 280d | 137d | $92,500 (5 Brutalis) TrueCrypt | 38y | 24y | $5.3M (288 Brutalis) VeraCrypt | 19381y | 11629y | $2.62B (141574 Brutalis)

eigth alphanumeric characters mixed with special character (eg 'pa$$W0Rd')

+ + + + + + + + +
hashAmazonBrutalisprice to crack in less than a month
+
      MD5 |      2d |    9.2h  | ~$362 (1 EC2 instance)
+    Skype |      2d |   17.7h  | ~$567 (1 EC2 instance)
+     WPA2 |    160y |     67y  | ~$14.9M (806 Brutalis)
+   SHA256 |      7d |      4d  | ~$2162 (1 EC2 instance)
+   BCrypt |   6194y |   1989y  | ~$448M (24,215 Brutalis)
+

AndroidPIN | 10y | 5y | ~$1.09M (59 Brutalis) MyWallet³ | 265d | 191d | ~$129500 (7 Brutalis) BitcoinWallet | 14996y | 5835y | ~$1.3B (71,038 Brutalis) LastPass | 24y | 12y | ~$2.6M (139 Brutalis) TrueCrypt² | 1144y | 718y | ~$162M (8,742 Brutalis) VeraCrypt¹ | 588867y | 353320y | ~$79.6B (4,301,668 Brutalis)

  1. VeraCrypt PBKDF2-HMAC-Whirlpool + XTS 512bit (super duper paranoid settings)

  2. TrueCrypt PBKDF2-HMAC-Whirlpool + XTS 512bit

  3. Blockchain MyWallet: https://blockchain.info/wallet/

a long memorisable pass sentence ('correct horse battery staple')

Okay, this doesn't need a table. It takes millions of billions of years to even crack this in MD5.

As illustration: The solar system needs around 225 Million years to rotate around the core of the Milkyway. This is the so called galactic year. The sun exists since around 20 galactic years. To crack such a password, even when hashed in MD5 takes 3 trillion (million million) galactic years.

Of course nobody would ever attempt to do this. There are many possibilities to crack a password faster. Explaining some of them would easily fill another article, so I leave you here. Sorry.

Links

To find your way into the topic, you might visit some of the following links:

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/2017-04-09-the-magic-0xc2/index.html b/zig-out/blog/2017-04-09-the-magic-0xc2/index.html new file mode 100644 index 0000000..bd6a800 --- /dev/null +++ b/zig-out/blog/2017-04-09-the-magic-0xc2/index.html @@ -0,0 +1,138 @@ + + + + + + the codeartist — programmer and engineer based in BerlinThe Magic 0xC2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

The Magic 0xC2

+ I built a web application with file upload functionality. Some Vue.js in the front and a CouchDB in the back. Everything should be pretty simple and straigt forward. But… +
+ Last updated: +
+ +

When I uploaded image files, they somehow got mangled. The uploaded file was bigger than the original and the new "file format" was not readable by any means. I got intrigued. What is it, that happens to the files? The changes seemed very random but reproducible, so I created a few test files to see what exactly changes and when.

My first file looked like this:

0123456789
+ABCDEFGHIJKLMNOPQRSTUVWXYZ
+abcdefghijklmnopqrstuvwxyz
+

To my surprise, the file stayed the same! My curiosity grew. In the meantime I found a very intriguing pattern in uploads hexdump: C3 BF C3. It was everywhere. In another file, I found similar patterns with C2. So I wrote my next test file. This time a binary file:

00 01 02 03 04 05 06 07  08 09 10 11 12 13 14 15 |................|
+16 17 18 19 20 21 22 23  24 25 26 27 28 29 30 31 |.... !"#$%&'()01|
+32 33 34 35 36 37 38 39  40 41 42 43 44 45 46 47 |23456789@ABCDEFG|
+48 49 50 51 52 53 54 55  56 57 58 59 60 61 62 63 |HIPQRSTUVWXY`abc|
+64 65 66 67 68 69 70 71  72 73 74 75 76 77 78 79 |defghipqrstuvwxy|
+80 81 82 83 84 85 86 87  88 89 90 91 92 93 94 95 |................|
+96 97 98 99 a0 a1 a2 a3  a4 a5 a6 a7 a8 a9 aa ab |................|
+ac ad ae af b0 b1 b2 b3  b4 b5 b6 b7 b8 b9 ba bb |................|
+00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
+

EDIT: As you probably already noticed, I counted up like in Base10 but it is actually Base16. So I skipped A-F until reaching A0. This might look weird but didn't affect the test.

The result after uploading was

00 01 02 03 04 05 06 07  08 09 10 11 12 13 14 15  |................|
+16 17 18 19 20 21 22 23  24 25 26 27 28 29 30 31  |.... !"#$%&'()01|
+32 33 34 35 36 37 38 39  40 41 42 43 44 45 46 47  |23456789@ABCDEFG|
+48 49 50 51 52 53 54 55  56 57 58 59 60 61 62 63  |HIPQRSTUVWXY`abc|
+64 65 66 67 68 69 70 71  72 73 74 75 76 77 78 79  |defghipqrstuvwxy|
+c2 80 c2 81 c2 82 c2 83  c2 84 c2 85 c2 86 c2 87  |................|
+c2 88 c2 89 c2 90 c2 91  c2 92 c2 93 c2 94 c2 95  |................|
+c2 96 c2 97 c2 98 c2 99  c2 a0 c2 a1 c2 a2 c2 a3  |................|
+c2 a4 c2 a5 c2 a6 c2 a7  c2 a8 c2 a9 c2 aa c2 ab  |................|
+c2 ac c2 ad c2 ae c2 af  c2 b0 c2 b1 c2 b2 c2 b3  |................|
+c2 b4 c2 b5 c2 b6 c2 b7  c2 b8 c2 b9 c2 ba c2 bb  |................|
+00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
+

There it was again: The magic 0xC2!

So all bytes with a value higher than 0x79 got followed by a 0xC2. 0x79 is the ASCII code for y. This is at least what I thought. It actually is the other way around: All bytes with value 0x80 or higher got prefixed by a 0xC2! — there the scales fell from my eyes: UTF-8 encoding!

In UTF-8 all characters after 0x7F are at least two bytes long. They get prefixed with 0xC2 until 0xC2BF (which is the inverted question mark ¿), which is then followed by 0xC380. So what happened is, that on the way to the server, the file got encoded to UTF-8 ¯\_(ツ)_/¯

EDIT: Corrected some mistakes after some comments on Hackernews

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/2017-08-17-vuejs-reactivity-from-scratch/index.html b/zig-out/blog/2017-08-17-vuejs-reactivity-from-scratch/index.html new file mode 100644 index 0000000..47783af --- /dev/null +++ b/zig-out/blog/2017-08-17-vuejs-reactivity-from-scratch/index.html @@ -0,0 +1,133 @@ + + + + + + the codeartist — programmer and engineer based in BerlinVuejs Reactivity From Scratch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Vuejs Reactivity From Scratch

+ Vuejs is the star newcomer in the Javascript Framework world. People love how it makes complicated things very simple yet performant. One of the more exciting features is its seemingly magic reactivity. Plain data objects in components magically invoke a rerender when a property changes. +
+ Last updated: +
+ +
+

NOTE: This is a copy of the original article from Aug 17th, 2017. You can read the archived original on archive.org

+

The button click invokes a function that just assigns a new value to a property. Still the template gets automagically rerendered. But we all know there is no fairydust involved, right? So how does it actually work?

The magic of getters and setters

With the ES5 standard JavaScript got lots of exciting new features. Some of them highly underrated and underused in my opinion. Getters and setters are an example. If you never heard of them, I would recommend you to read John Riesigs piece on them.

As soon as you know what getters and setters are: functions transparently called on every property access, you might already know where this goes. Boom! All the fairydust suddenly disappears.

Automatic getters and setters

Now that we at least in theory know how Vuejs realises the template data magic, let's build it ourselves for the sake of full understanding!

Abstract: A function that gets an object and returns one with the properties replaced by getters and setters that, on call, rerender a template. So far so good. If you are really impatient, you can find the final code in JSFiddle.

Let's start with a very simple approach:

+

The function iterates through all object keys and creates a new object with getters and setters in their place. It could also directly manipulate the original object:

+

I personally don't like to manipulate the existing object and prefer the first way.

Introducing: Object.defineProperty

Now before we go on with destroying our fantasies of fairydust computing, let's see if there is a more convenient way to what we've done for now. Here I introduce Object.defineProperty, which allows to set all possible attributes for the properties of an object. You can find a detailed description on MDN.

With this new knowlegde, the code can be made a bit more readable, by condensing everything into one call:

+

All those underscores where pretty annoying anyways. I generally suggest you to read more about Object.defineProperty. It extends the range of possibilities significantly!

Templating for the poor

To be able to rerender a component on data change, we should really introduce some components that can actually render and under the right circumstances rerender a template.

+

This code describes a very simple component, that has a data object and a render function. If this is called, it replaces the innerHTML of the given content element with the rendered output. Neat! Let's make the data reactive!

Reactive Component

As a start, it should be enough to simply make the data property reactive:

+

Yes, that seems to be good but it doesn't really update the template. Which becomes clear after a look at line 11-14: There is no render call ever. But reactive shouldn't know about component rendering, right? Let's try a more general approach with a callback:

+

Yeah, that works and so on but it looks like we slowly stumble away from elegance in our code. The changes in reactive() seem to be okay, but that function bind monstrosity in line 31 is something we better hide from our parents. Let's introduce a component factory before we get kicked out or end up in self hatred:

+

Cool! That works. The createComponent() function just does all the dirty work for us and returns a nice, reactive component, that is still just a simple object. If you have that code in a local setup and run something like component.data.name = 'Ada Lovelace', then it will automagically rerender the template to show 'Hello Ada Lovelace'.

Nested Data structures

All cool and hip stuff but what happens in the following scenario:

+

Setting deeper nested properties (line 44,45) doesn't work at all. The reason is that the reactivity only works on the first nesting level of the data object. Now you could say: Easy, we just set the whole object at once:

+

But this is not really what we strive for, isn't it? What we need is a way that makes all nested objects reactive in a recursive way. Surprisingly, this just needs a coupe of lines:

+

Only three lines (7-9) where added. They call reactive() on the given value in case it is an object. Now the nesting level doesn't matter anymore. REACTIVE ALL THE THINGS!!

Multiple Components

Considering that components are usually very gregarious, what happens if we find a friend for our component? Will it blend? Erm I mean, react?

+

It does! Hooray!

The attentive reader might have seen the change that sneaked into line 7: Because the type of array is object, an extra check has to be made here. Otherwise the array would be transformed to a plain object with keys 0, 1, etc.

But what happens now when we manipulate the Array directly?

+

Bummer! Setting the whole array works as expected but manipulating it doesn't trigger any change.

Reactive Arrays

As described in the caveats section of the Vuejs guide about list rendering, there are several …well caveats with array reactivity. It writes:

Due to limitations in JavaScript, Vue cannot detect the following changes to an array:
+1. When you directly set an item with the index, e.g. vm.items[indexOfItem] = newValue
+2. When you modify the length of the array, e.g. vm.items.length = newLength
+

Okay, fair enough. So what does happen in Vue to make Arrays reactive? Fairydust? Unfortunately yes. And this stuff is expensive! Nah, just kidding. Of course it is again no magic involved. I'm sorry my dear role-playing friends. What actually happens is that Arrays get their manipulating functions replaced by a wrapped version that notifies the component about changes. The source to this functionality is in core/observer/array.js.

Vuejs' approach is rather sophisticated but can be condensed down to something like what is seen in the first 24 lines here:

+

So this is a fairly big chunk to digest. The new function reactiveArray starts with creating a copy of the original array (Remember? I don't like manipulating the original object). Then, for each function in the list of manipulative array functions the original is saved which is then replaced by a wrapper function. This wrapper function simply calls the render callback additionally to the original array function.

Now also lipsumComponent.data.content is not set directly anymore but uses the overwritten push method. Setting it directly wouldn't work. Fixing that leads us to the last step:

Reactivity on set

For now the setter function didn't care about the value. If it would be a nested object, its children wouldn't be reactive. That means, if you set data.x to an object {foo: 1} and then change foo data.x.foo++, the template wouldn't rerender. This should be changed:

+

Instead of setting the plain value, reactive(value, callback) is called in line 49. This small change works only up to a certain point on its own though. The function has to decide what to do with non-objects or arrays, which happens now as a first step in reactive(). A plain non-object (remember: arrays are objects) simply gets returned as it is (line 30), arrays will be returned in their reactive version (line 31).

Conclusion

Congratulations! You made it this far or just skipped to read only the Conclusion, which is fine, I do that too sometimes.

In about 70 SLOC, we built a fully reactive component system. We made use of getters, setters and Object.defineProperty and learned, that I don't like to manipulate objects directly. Except for the last point, this should be valuable information that might become handy in future.

What else can be done you might ask? Vuejs' code is more sophisticated and handles some egde cases that I didn't mention for the sake of simplicity. For example if the yet to become reactive object has some getters and/or setters already, they would be overwritten by our simple solution. Vuejs' defineReactive uses Object.getOwnPropertyDescription to get a detailed information about the property it is going to wrap and incorporates existing getters and setters if applicable. It also ignores non-configurable (not meant to be changed at all) properties. How that works can be found in the source code.

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/2019-01-10-running-write-freely-on-arm/index.html b/zig-out/blog/2019-01-10-running-write-freely-on-arm/index.html new file mode 100644 index 0000000..8542a9b --- /dev/null +++ b/zig-out/blog/2019-01-10-running-write-freely-on-arm/index.html @@ -0,0 +1,205 @@ + + + + + + the codeartist — programmer and engineer based in BerlinRunning writefreely 0.7 on Arm + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Running writefreely 0.7 on Arm

+ What was necessary to make cross-compiling work for newer WriteFreely versions with SQLite support. +
+ Last updated: +
+ +

This is a follow-up on The expected tutorial: How to install WriteFreely on a Raspberry pi 3 in 10 steps.

I did it! I finally got WriteFreely to run on my Arm server (check out Scaleways baremetal cloud servers).

It wasn't so easy because with 512MB of RAM I couldn't simply download and build the source on my webserver. Only solution: Cross compiling. Easy especially in Go, right?

If you read the article linked in the beginning you know how easy it could be. But as the article already mentions in an update, since Version 0.6 it is not working anymore because of the new SQLite dependency (newest version as of writing this article is 0.7).

With a bit of research I figured out what to do to make it work anyhow. There are two solutions. A quick (and slightly dirty) one for people who don't need SQLite support and a correct solution that needs a tad more effort.

Quick solution: remove SQLite support

SQLite support makes problems with the cross compiling because it needs some C code to be compiled. Before figuring out how to make this working with the otherwise super easy Go cross compiling, removing the feature might be a viable quick fix. For this, simply change or remove all occurences of sqlite in the Makefile:

diff --git a/Makefile b/Makefile
+index 5950dfd..032fd0c 100644
+--- a/Makefile
++++ b/Makefile
+@@ -13,25 +13,25 @@ IMAGE_NAME=writeas/writefreely
+ all : build
+ 
+ build: assets deps
+-	cd cmd/writefreely; $(GOBUILD) -v -tags='sqlite'
++	cd cmd/writefreely; $(GOBUILD) -v
+ 
+ build-linux: deps
+ 	@hash xgo > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
+ 		$(GOGET) -u github.com/karalabe/xgo; \
+ 	fi
+-	xgo --targets=linux/amd64, -dest build/ $(LDFLAGS) -tags='sqlite' -out writefreely ./cmd/writefreely
++	xgo --targets=linux/amd64, -dest build/ $(LDFLAGS) -out writefreely ./cmd/writefreely
+ 
+ build-windows: deps
+ 	@hash xgo > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
+ 		$(GOGET) -u github.com/karalabe/xgo; \
+ 	fi
+-	xgo --targets=windows/amd64, -dest build/ $(LDFLAGS) -tags='sqlite' -out writefreely ./cmd/writefreely
++	xgo --targets=windows/amd64, -dest build/ $(LDFLAGS) -out writefreely ./cmd/writefreely
+ 
+ build-darwin: deps
+ 	@hash xgo > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
+ 		$(GOGET) -u github.com/karalabe/xgo; \
+ 	fi
+-	xgo --targets=darwin/amd64, -dest build/ $(LDFLAGS) -tags='sqlite' -out writefreely ./cmd/writefreely
++	xgo --targets=darwin/amd64, -dest build/ $(LDFLAGS) -out writefreely ./cmd/writefreely
+ 
+ build-docker :
+ 	$(DOCKERCMD) build -t $(IMAGE_NAME):latest -t $(IMAGE_NAME):$(GITREV) .
+@@ -40,11 +40,11 @@ test:
+ 	$(GOTEST) -v ./...
+ 
+ run: dev-assets
+-	$(GOINSTALL) -tags='sqlite' ./...
++	$(GOINSTALL) ./...
+ 	$(BINARY_NAME) --debug
+ 
+ deps :
+-	$(GOGET) -tags='sqlite' -v ./...
++	$(GOGET) -v ./...
+ 
+ install : build
+ 	cmd/writefreely/$(BINARY_NAME) --gen-keys
+@@ -77,10 +77,10 @@ ui : force_look
+ 	cd less/; $(MAKE) $(MFLAGS)
+ 
+ assets : generate
+-	go-bindata -pkg writefreely -ignore=\\.gitignore schema.sql sqlite.sql
++	go-bindata -pkg writefreely -ignore=\\.gitignore schema.sql
+ 
+ dev-assets : generate
+-	go-bindata -pkg writefreely -ignore=\\.gitignore -debug schema.sql sqlite.sql
++	go-bindata -pkg writefreely -ignore=\\.gitignore -debug schema.sql
+ 
+ generate :
+ 	@hash go-bindata > /dev/null 2>&1; if [ $$? -ne 0 ]; then \
+
+

Now just go on as described in the original article and it should work:

env GOARCH=arm GOARM=7 go get github.com/writeas/writefreely/cmd/writefreely
+
+

The correct solution

To get WriteFreely cross compiled with SQLite support, a C cross compiler is needed. Void Linux, the distribution of my choice, offers a bunch of packages for all kind of architectures. They are called for example cross-armv7l-linux-gnueabihf (ARMv7), cross-arm-linux-gnueabihf (ARMv6) or cross-arm-linux-gnueabi (ARMv5). I found similar packages in AUR (for Arch Linux).

As soon as the corresponding cross compiler is found, go can be told to use it:

env CGO_ENABLED=1 CC=armv7l-linux-gnueabihf-gcc GOOS=linux GOARCH=arm GOARM=7 make
+
+

The environment variables used are:

CGO_ENABLED=1 should be obvious. It tells Go to enable the C compilation.

CC=armv... tells Go which C compiler to use. Usually this would be just gcc. In this case it is the name of the cross compiler. Please set it to the compiler for your target platform. I'm going to use ARMv7 examples here. It is the name of a directory found in /usr/, eg /usr/armv7l-linux-gnueabihf. Initially that failed for me though because it expected to find a file ./lib/libc.so which ended up in another subfolder /usr/. So I cheated a bit and did:

# You might not need to do this on your platform.
+sudo ln -s /usr/armv7l-linux-gnueabihf/usr/lib /usr/armv7l-linux-gnueabihf/lib
+
+

GOOS=linux GOARCH=arm are the same as in the original article.

GOARM=7 is optional, even on an actual ARMv7. It enables some register optimizations that only work on ARMv7.

And finally make is called. This is short for make all which should do everything necessary.

Not all files are necessary to be transferred to the Server or RaspberryPi. What I did after some experimentation was:

# after building everything create a package
+mkdir writefreely-arm
+cp -r templates pages static writefreely-arm
+mkdir writefreely-arm/keys # fun fact: key generation crashes without this
+cp cmd/writefreely/writefreely writefreely-arm
+tar cvzf writefreely-arm.tgz writefreely-arm
+
+# copy that package to the server
+scp writefreely-arm.tgz you@yourserver.tld:~
+
+# ssh into the server and unpack everything
+ssh you@yourserver.tld
+tar czf writefreely-arm.tgz
+cd writefreely-arm
+
+# generate config, keys and database
+./writefreely -config # starts interactive configuration
+
+# This should lead you through all necessary steps
+# like filling the config, generating keys, generating database tables
+# run `./writefreely --help` to learn more if something is missing.
+
+

Now ./writefreely should run an empty blog at the specified port.

Have fun!

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux/index.html b/zig-out/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux/index.html new file mode 100644 index 0000000..b48f393 --- /dev/null +++ b/zig-out/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux/index.html @@ -0,0 +1,133 @@ + + + + + + the codeartist — programmer and engineer based in BerlinUse OpenBSDs Spleen bitmap font in Linux + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Use OpenBSDs Spleen bitmap font in Linux

+ Yesterday Frederic Cambus changed the default console font in OpenBSD to his self made font. +
+ Last updated: +
+ +

The font is called Spleen, as mentioned in this BSD Journal article.

To be totally honest, I stopped thinking about TTY (aka console) fonts a long time ago. It just happened to get interesting again when I got a HiRes screen and suddenly a magnifying glass was necessary to read the TTY. Yes I am one of those people who still deny the existence of graphical installers. If you want to change my mind, feel free to write me.

Anyhow, I figured that Spleen is pretty and useful because it offers glyphs with sizes up to 32x64. Typical fonts in Void Linux are 8x16 or similar, which is very small on high DPI screens. But how to use them? Spleen comes in strange formats like BDF or .dfont but we need another strange format called PSFU. If we look at the description that comes with Spleen we only get tought how to make yet another strange format called PCF. Puh, so confusing. Fonts must have been a real pain back in the "good old times".

If you managed to read this until this point, I congratulate you. You won a short list of commands:

# assuming bdf2psf is installed
+FONTDIR=/usr/share/kbd/consolefonts   # or anything you want
+SPLEENDIR=$HOME/src/spleen             # or whereever you want the repo
+EQUIV=/usr/share/bdf2psf/standard.equivalents # check bdf2psf manpage
+FONTSET=/usr/share/bdf2psf/fontsets/Uni1.512 # check bdf2psf manpage
+
+git clone https://github.com/fcambus/spleen.git $SPLEENDIR
+
+for x in 12x24 16x32 32x64 5x8 8x16 # do it for all available sizes
+do
+    bdf2psf --fb \
+        ${SPLEENDIR}/spleen-${x}.bdf \
+        $EQUIV $FONTSET 512 \
+        ${FONTDIR}/spleen-${x}.psfu
+done
+
+# assuming you're in the TTY
+setfont ${SPLEENDIR}/spleen-16x32.psfu
+
+

That worked for me! Except spleen-32x64 didn't work for me. It might be too big for Linux TTYs but would be too big anyways. Lets wait for 8K displays.

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/2019-05-03-freddy-vs-json/index.html b/zig-out/blog/2019-05-03-freddy-vs-json/index.html new file mode 100644 index 0000000..e042a94 --- /dev/null +++ b/zig-out/blog/2019-05-03-freddy-vs-json/index.html @@ -0,0 +1,599 @@ + + + + + + the codeartist — programmer and engineer based in BerlinFreddy vs JSON: how to make a top-down shooter + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Freddy vs JSON: how to make a top-down shooter

+ I will tell you how I created a simple top-down shooter in JavaScript without using any additional libraries. But this article is not replicating the full game but instead tries to show which steps to take to start writing a game from scratch. +
+ Last updated: +
+ +

A couple of years ago (Oh it's almost a decade! Am I that old already?), when the Canvas API got widely adopted by most browsers, I started experimenting with it. The fascination was high and I immediately tried to use it for interactive toys and games.

Of course, the games I made (and make) are usually not very sophisticated. That is mainly because I create them only for fun and without much eye-candy or even sound. What really fascinates me is the underlying mechanics. Otherwise, I could just use one of those awesome game engines, that exist already.

To share some of the fun, I created a tiny top down shooter for a tech session in my company (we're hiring, btw). The result can be found on Github. I commented the code well so it should be quite helpful to just read it. But if you want to know how I created the game step-by-step, this article is for you.

The Game

To give you an impression of what I created:

screenshot

The little gray box is your ship. You are controlling the little gray box with either WASD or Arrow keys and you can shoot tiny yellow boxes at your enemies — the red boxes — by pressing Space or Enter. The enemies shoot back though. They don't really aim well, but at some point they'll flood the screen with tiny red boxes. If they hit you, they hurt. Every time you get hurt you shrink, until you completely disappear. The same happens with your opponents.

Preconditions

This post is not about the game itself but about the underlying mechanics and some of the tricks used to make it work. My intention is to provide an entry for understanding more complex game development for people with some existing programming experience. The following things are helpful to fully understand everything:

Fundamental Game Engine Mechanics

Most — if not all — game engines have the same fundamental building blocks:

  • The state, that defines the current situation (like main menu, game running, game lost, game won, etc).

  • A place to store all the objects and related data.

  • The main loop, usually running sixty times per second, that reads the object information, draws the screen and applies updates to object data

  • An event handler that maps key presses, mouse movements and clicks to data changes.

The Canvas Element

The Canvas element allows you to handle pixel based data directly inside the browser. It gives you a few functions to draw primitives. It is easy to draw, for example, a blue rectangle but you need more than one action to draw a triangle; to draw a circle you need to know how to use arcs.

Exactly because drawing rectangles is the easiest and fastest thing to do with the Canvas API, I used them for everything in Freddy vs JSON. That keeps the complexities of drawing more exciting patterns or graphics away and helps focus on the actual game mechanics. This means, after initializing the canvas besides setting colors we only use two functions:

const ctx = canvas.getContext('2d') // this is the graphics context
+ctx.fillStyle = '#123456'           // use color #123456
+
+ctx.fillText(text, x, y)            // write 'text' at coords x, y
+ctx.fillRect(x, y, width, height)   // draw filled rectangle
+
+

Step One: Some HTML and an initialized Canvas

Because the code is going to run in the browser, some HTML is necessary. A minimal set would be just the following two lines:

<canvas id="canvas" />
+<script src="./app.js"></script>
+
+

This works but of course some styling would be great. And maybe having a title? Check out a complete version on Github.

Initializing a Canvas is also pretty simple. Inside app.js following lines are necessary:

const canvas = document.getElementById('canvas')
+// you can set height and width in HTML, too
+canvas.width = 960
+canvas.height = 540
+const ctx = canvas.getContext('2d')
+
+

I chose rather arbitrary values for width and height. Feel free to change them to your liking. Just know that higher values obviously will result in more work for your computer.

Step Two: Game Mode / States

To avoid creating a big ball of mud it is common to use a state machine. The idea is to describe the high level states and their valid transitions and using a central state handler to control them.

There libraries that help with state machines, but it is also not too hard to create this yourself. In the game I created I used a very simple state machine implementation: The possible states and their transitions are described in Enum-like objects. Here some code to illustrate the idea. The code uses some rather new language features: Symbols and Computed Property Names.

const STATE = {
+  start: Symbol('start'),  // the welcome screen
+  game: Symbol('game'),    // the actual game
+  pause: Symbol('pause'),  // paused game
+  end: Symbol('end')       // after losing the game
+}
+
+const STATE_TRANSITION = {
+  [STATE.start]: STATE.game, // Welcome screen => Game
+  [STATE.game]: STATE.pause, // Game => Pause
+  [STATE.pause]: STATE.game, // Pause => Game
+  [STATE.end]: STATE.start   // End screen => Welcome screen
+}
+
+

This is not a full state machine but does the job. For the sake of simplicity I violate the state machine in one occasion though: There is no transition from the running game to the end of the game. This means I have to jump directly, without using the state handler, to the end screen after the player dies. But this saved me from a lot of complexity. Now the state control logic is effectively only one line:

newState = STATE_TRANSITION[currentState]
+
+

Freddy vs JSON uses this in the click handler. A click into the canvas changes the state from welcome screen to the actual game, pauses and un-pauses the game and brings you back to the welcome screen after losing. All that in only one line. The new state is set to a variable that is respected by the central update loop. More on that later.

Of course much more could be done with a state. For example weapon or ship upgrades could be realised. The game could transition towards higher difficulty levels and get special game states like an upgrade shop or transfer animations between stages. Your imagination is the limit. And the amount of lines in your state handler, I guess.

Step Three: Data Handling

Games usually have to handle a lot of information. Some examples are the position and health of the player, the position and health of each enemy, the position of each single bullet that is currently flying around and the amount of hits the player landed so far.

JavaScript allows different ways to handle this. Of course, the state could just be global. But we all (should) know that global variables are the root of all evil. Global constants are okay because they stay predictable. Just don't use global variables. If you're still not convinced, please read this entry on stackexchange.

Instead of global variables, you can put everything into the same scope. A simple example is shown next. The following code examples use template literals, a new language feature. Learn more about template literals here.

function Game (canvas) {  // the scope
+  const ctx = canvas.getContext('2d')
+  const playerMaxHealth = 10
+  let playerHealth = 10
+
+  function handleThings () {
+    ctx.fillText(`HP: ${playerHealth} / ${playerMaxHealth}`, 10, 10)
+  }
+}
+
+

This is nice because you have easy access just like with global variables without actually using global variables. It still opens the door to potential problems if you only have one big scope for everything, but the first game is probably small enough to get away with not thinking about this too much.

Another way is to use classes:

class Game {
+  constructor (canvas) {
+    this.ctx = canvas.getContext('2d')
+    this.playerMaxHealth = 10
+    this.playerHealth = 10
+  }
+
+  handleThings () {
+    const max = this.playerMaxHealth
+    const hp = this.playerHealth
+    ctx.fillText(`HP: ${hp} / ${max}`, 10, 10)
+  }
+}
+
+

That looks like a bit more boilerplate but classes are good to encapsulate common functionality. They get even better if your game grows and you want to stay sane. But in JavaScript they are just syntactical sugar. Everything can be achieved with functions and function scopes. So it is up to you, what you use. The two last code examples are essentially the same thing.

Now that we decided on how to save all the data (Freddy vs JSON uses a class so I'll use classes here too) we can further structure it... or not. Freddy vs JSON saves everything flat. That means for example that each player attribute gets its own variable instead of using a player object that contains a lot of properties. The latter is probably more readable so you might want to go this path. Object access is also pretty fast nowadays so there is probably not a noticeable difference if you write this.player.health instead of this.playerHealth. If you are really serious about performance though, you might want to investigate this topic further. You can check out my jsperf experiment for a start.

Data manipulation happens in the update loop or when handling events. The next steps explain these topics further.

Step Four: The Main Loop

If event based changes are enough, like on a website, a separate loop wouldn't be necessary. The user clicks somewhere, which triggers an event that updates something and eventually re-renders a part of the page. But in a game some things happen without direct user interaction. Enemies come into the scene and shoot at you, there might be some background animation, music plays, and so on. To make all this possible a game needs an endlessly running loop which repeatedly calls a function that checks and updates the status of everything. And to make things awesomely smooth it should call this function in a consistent interval — at least thirty, better sixty times per second.

The following code examples use another rather new language feature called Arrow Functions.

Typical approaches to run a function in an regular interval would include the usage of setInterval:

let someValue = 23
+setInterval(() => {
+  someValue++
+}, 16)
+
+

Or setTimeout

let someValue = 42
+
+function update () {
+  someValue++
+  setTimeout(update, 16)
+}
+
+update()
+
+

The first version just runs the function endlessly every sixteen milliseconds (which makes sixty-two and a half times per second), regardless of the time the function itself needs or if is done already. The second version does its potentially long running job before it sets a timer to start itself again after sixteen milliseconds.

The first version is especially problematic. If a single run needs more than sixteen milliseconds, it runs another time before the first run finished, which might lead to a lot of fun, but not necessarily to any useful result. The second version is clearly better here because it only sets the next timeout after doing everything else. But there is still a problem: Independent of the time the function needs to run it will wait an additional sixteen milliseconds to run the function again.

To mitigate this, the function needs to know how long it took to do its job and then substract that value from the waiting time:

let lastRun
+let someValue = 42
+
+function update () {
+  someValue++
+  const duration = Date.now() - lastRun
+  const time = duration > 16 ? 0 : 16 - time
+  setTimeout(update, time)
+  lastRun = Date.now()
+}
+
+lastRun = Date.now()
+update()
+
+

Date.now() returns the current time in milliseconds. With this information we can figure out how much time has passed since the last run. If more than sixteen milliseconds have passed since then just start the update immediately and crush that poor computer (or better slow down the execution time and be nice to the computer), otherwise wait as long as necessary to stay at around sixty runs per second.

Please note that Date.now() is not the best way to measure performance. To learn more about performance and high resolution time measurement, check out: https://developer.mozilla.org/en-US/docs/Web/API/Performance

Cool. This way you can also slow everything down to a chill thirty frames per second by setting the interval to thirty-three milliseconds. But lets not go that path. Lets do what the cool kids with their shiny new browsers do. Lets use requestAnimationFrame.

requestAnimationFrame takes your update function as an argument and will call it right before the next repaint. It also gives you the timestamp of the last call, so that you don't have to ask for another one, which potentially impacts your performance. Lets get down to the details:

function update () {
+  /* do some heavy calculations */
+  requestAnimationFrame(update)
+}
+
+update()
+
+

This is the simplest version. It runs your update function as close as possible to the next repaint. This means it usually runs sixty times per second, but the rate might be different depending on the screen refresh rate of the computer it runs on. If your function takes longer than the duration between screen refreshes, it will simply skip some repaints because it is not asking for a repaint before it is finished. This way it will always stay in line with the refresh rate.

A function that does a lot of stuff might not need to run that often. Thirty times per second is usually enough to make things appear smooth and some other calculations might not be necessary every time. This brings us back to the timed function we had before. In this version we use the timestamp that requestAnimationFrame is giving us when calling our function:

let lastRun
+
+function update (stamp) {
+  /* heavy work here */
+  lastRun = stamp
+
+  // maybe 30fps are enough so the code has 33ms to do its work
+  if (stamp - lastRun >= 33) {
+    requestAnimationFrame(update)
+  }
+}
+
+// makes sure the function gets a timestamp
+requestAnimationFrame(update)
+
+

Step Five: Event Handling

People usually want to feel like they are in control of what they are doing. This brings us to a point where the game needs to handle input from the user. Input can be either a mouse movement, a mouse click or a key press. Key presses are also separated into pressing and releasing the key. I'll explain why later in this section.

If your game is the only thing running on that page (and it deserves that much attention, doesn't it?) input events can simply be bound to document. Otherwise they need to be bound to the canvas event directly. The latter can be more complicated with key events because key events work best with actual input fields. This means you need to insert one into the page, and make sure it stays focused so that it gets the events. Each click into the canvas would make it lose focus. To avoid that, you can use the following hack:

inputElement.onblur = () => inputElement.focus()
+
+

Or you simply put everything to its own page and bind the event listeners to document. It makes your life much easier.

Side note: People might wonder why I don't use addEventListener. Please use it if it makes you feel better. I don't use it here for simplicity reasons and it will not be a problem as long as each element has exactly one event listener for each event type.

Mouse Movement

Mouse movements are not really used in Freddy vs JSON but this post wouldn't be complete without explaining them. So this is how you do it:

canvas.onmousemove = mouseMoveEvent => {
+  doSomethingWithThat(mouseMoveEvent)
+}
+
+

This will be executed on every little movement of the mouse as long as it is on top of the canvas. Usually you want to debounce that event handler because the event might fire at crazy rates. Another way would be to use it only for something very simple, like to save the mouse coordinates. That information can be used in a function that is not tied to the event firing, like our update function:

class Game {
+  constructor (canvas) {
+    // don't forget to set canvas width and height,
+    // if you don't do it, it will set to rather
+    // small default values
+    this.ctx = canvas.getContext('2d')
+    this.mouseX = 0
+    this.mouseY = 0
+
+    // gets called at every little mouse movement
+    canvas.onmousemove = event => {
+      this.mouseX = event.offsetX
+      this.mouseY = event.offsetY
+    }
+
+    this.update()
+  }
+
+  // gets called at each repaint
+  update () {
+    requestAnimationFrame(() => this.update())
+    this.fillRect('green', this.mouseX, this.mouseY, 2, 2)
+  }
+}
+
+

The MouseEvent object contains a lot more useful information. I suggest you to check out the link and read about it.

This should draw two pixel wide boxes wherever you touch the canvas with your mouse. Yeah, a drawing program in ten lines! Photoshop, we're coming for you!

Mouse Clicks

But lets get back to reality. Mouse clicks are another important interaction:

canvas.onclick = mouseClickEvent => {
+  doSomethingWithThat(mouseClickEvent)
+}
+
+

The event object again contains all kind of useful information. It is the same type of object that you get from mouse movement. Makes life simpler, doesn't it?

Now to make use of the mouse clicks, lets adapt the former code example:

class Game {
+  constructor (canvas) {
+    // set canvas.width and canvas.height here
+    this.ctx = canvas.getContext('2d')
+    this.mouseX = 0
+    this.mouseY = 0
+    this.drawing = false
+
+    canvas.onmousemove = event => {
+      this.mouseX = event.offsetX
+      this.mouseY = event.offsetY
+    }
+    canvas.onmousedown = () => {
+      this.drawing = true
+    }
+    canvas.onmouseup = () => {
+      this.drawing = false
+    }
+
+    this.update()
+  }
+
+  update () {
+    requestAnimationFrame(() => this.update())
+    if (this.drawing) {
+      this.fillRect('green', this.mouseX, this.mouseY, 2, 2)
+    }
+  }
+}
+
+

Check it out on CodeSandbox

Now the boxes are only drawn while holding down the mouse button. Boom, one step closer to the ease of use of Photoshop! It is incredible, what you can do with it already. Just check out this incredible piece of art:

incredible piece of art

Key Events

The last important input comes from key presses. Okay, it is not really the last input type. Other ones would come from joysticks or gamepads. But there are some old-school people like me who still prefer using the keyboard to navigate their space ship.

Input handling is theoretically simple but in practice it is everything but. That's why this section explains not only how key events work but also how to get them right. Look forward to event handling, the relationship between velocity and acceleration, and frame rate agnostic timing...

The simplest version of key event handling looks like this:

document.onkeypress = keyPressEvent => {
+  doSomethingWithThat(keyPressEvent)
+}
+
+

But keypress is deprecated and should not be used. It is anyways better to separate the keyPress into two events: KeyDown and KeyUp and I'll explain why.

For now imagine you have that awesome space ship in the middle of the screen and want to make it fly to the right if the user presses d or ArrowRight:

class Game {
+  constructor(canvas, width, height) {
+    // we'll need those values
+    this.width = canvas.width = width;
+    this.height = canvas.height = height;
+    this.ctx = canvas.getContext("2d");
+
+    this.shipSize = 10;
+    this.shipHalf = this.shipSize / 2.0; // you'll need that a lot
+
+    // position the ship in the center of the canvas
+    this.shipX = width / 2.0 - this.shipHalf;
+    this.shipY = height / 2.0 - this.shipHalf;
+
+    // event is a KeyboardEvent:
+    // https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
+    document.onkeypress = event => {
+      const key = event.key;
+      if (key === "d" || key === "ArrowRight") {
+        this.shipX++;
+      }
+    };
+
+    this.update();
+  }
+
+  // convenience matters
+  rect(color, x, y, w, h) {
+    this.ctx.fillStyle = color;
+    this.ctx.fillRect(x, y, w, h);
+  }
+
+  update() {
+    // clean the canvas
+    this.rect("black", 0, 0, this.width, this.height);
+
+    // get everything we need to draw the ship
+    const size = this.shipSize;
+    const x = this.shipX - this.shipHalf;
+    const y = this.shipY - this.shipHalf;
+
+    // draw the ship
+    this.rect("green", x, y, size, size);
+
+    // redraw as fast as it makes sense
+    requestAnimationFrame(() => this.update());
+  }
+}
+
+

check it out on CodeSandbox

Okay, that is kinda working, at least if you press d. But the arrow key is somehow not working and the ship's movement feels a bit jumpy. That doesn't seem to be optimal.

The problem is that we're relying on repeated key events. If you press and hold a key, the keypress event is repeated a couple of times per second, depending on how you set your key repeat rate. There is no way to use that for a smooth movement because we can not find out how fast the users keys are repeating. Sure, we could try to measure the repeat rate, hoping the user holds the key long enough. But let's try to be smarter than that.

Lets recap: We hold the key, the ship moves. We leave the key, the movement stops. That is what we want. What a happy coincidence that these two events have ...erm.. events:

class Game {
+  constructor(canvas, width, height) {
+    // we'll need those values
+    this.width = canvas.width = width;
+    this.height = canvas.height = height;
+    this.ctx = canvas.getContext("2d");
+
+    this.shipSize = 10;
+    this.shipHalf = this.shipSize / 2.0; // you'll need that a lot
+
+    // position the ship in the center of the canvas
+    this.shipX = width / 2.0 - this.shipHalf;
+    this.shipY = height / 2.0 - this.shipHalf;
+
+    this.shipMoves = false;
+
+    // key is pressed down
+    document.onkeydown = event => {
+      const key = event.key;
+      switch (key) {
+        case "d":
+        case "ArrowRight":
+          this.shipMoves = "right";
+          break;
+        case "a":
+        case "ArrowLeft":
+          this.shipMoves = "left";
+          break;
+        case "w":
+        case "ArrowUp":
+          this.shipMoves = "up";
+          break;
+        case "s":
+        case "ArrowDown":
+          this.shipMoves = "down";
+          break;
+      }
+    };
+
+    document.onkeyup = () => {
+      this.shipMoves = false;
+    };
+
+    this.update();
+  }
+
+  // convenience matters
+  rect(color, x, y, w, h) {
+    this.ctx.fillStyle = color;
+    this.ctx.fillRect(x, y, w, h);
+  }
+
+  update() {
+    // move the ship
+    if (this.shipMoves) {
+      if (this.shipMoves === "right") this.shipX++;
+      else if (this.shipMoves === "left") this.shipX--;
+      else if (this.shipMoves === "up") this.shipY--;
+      else if (this.shipMoves === "down") this.shipY++;
+    }
+
+    // clean the canvas
+    this.rect("black", 0, 0, this.width, this.height);
+
+    // get everything we need to draw the ship
+    const size = this.shipSize;
+    const x = this.shipX - this.shipHalf;
+    const y = this.shipY - this.shipHalf;
+
+    // draw the ship
+    this.rect("green", x, y, size, size);
+
+    // redraw as fast as it makes sense
+    requestAnimationFrame(() => this.update());
+  }
+}
+
+

check it out on CodeSandbox

I felt like adding all directions right away. Now the movement itself is decoupled from the key events. Instead of changing the coordinates directly on each event, a value is set to a movement direction and the main loop takes care of adapting the coordinates. That's great because we don't care about any key repeat rates anymore.

But there are still some problems here. First of all, the ship can only move in one direction at a time. Instead it should always be able to move in two directions at a time, like up- and leftwards. Then the movement stops if the switch from one key to another is too fast. That might happen in a heated situation between your ship and the enemies bullets. Also the movement is bound to the frame rate. If the frame rate drops or the screen refreshes on a different rate on the players computer, your ship becomes slower or faster. And last but not least the ship simply jumps to full speed and back to zero. For a more natural feeling it should instead accelerate and decelerate.

Lots of work. Lets tackle the problems one by one:

Bidirectional movements are easy to do. We just need a second variable. And to simplify things even more, we can set these variables to numbers instead of identifying strings. Here you see why:

class Game {
+  constructor(canvas, width, height) {
+    /* ... same as before ... */
+
+    this.shipMovesHorizontal = 0;
+    this.shipMovesVertical = 0;
+
+    // this time, the values are either positive or negative
+    // depending on the movement direction
+    document.onkeydown = event => {
+      const key = event.key;
+      switch (key) {
+        case "d":
+        case "ArrowRight":
+          this.shipMovesHorizontal = 1;
+          break;
+        case "a":
+        case "ArrowLeft":
+          this.shipMovesHorizontal = -1;
+          break;
+        case "w":
+        case "ArrowUp":
+          this.shipMovesVertical = -1;
+          break;
+        case "s":
+        case "ArrowDown":
+          this.shipMovesVertical = 1;
+          break;
+      }
+    };
+
+    // to make this work, we need to reset movement
+    // but this time depending on the keys
+    document.onkeyup = event => {
+      const key = event.key;
+      switch (key) {
+        case "d":
+        case "ArrowRight":
+        case "a":
+        case "ArrowLeft":
+          this.shipMovesHorizontal = 0;
+          break;
+        case "w":
+        case "ArrowUp":
+        case "s":
+        case "ArrowDown":
+          this.shipMovesVertical = 0;
+          break;
+      }
+    };
+
+    this.update();
+  }
+
+  /* more functions here */
+
+  update() {
+    // move the ship
+    this.shipX += this.shipMovesHorizontal;
+    this.shipY += this.shipMovesVertical;
+
+    /* drawing stuff */
+  }
+}
+
+

Find the full version on CodeSandbox

This not only allows the ship to move in two directions at the same time, it also simplifies everything. But there's still the problem, that fast key presses don't get recognized well.

What actually happens in those stressful moments is correct from the code's point of view: If a key of the same dimension (horizontal or vertical) is pressed, set the movement direction, if it is released set movement to zero. But humans are not very exact. They might press the left arrow (or a) a split second before they fully released the right arrow (or d). This way, the function switches the movement direction for that split second but then stops because of the released key.

To fix this, the keyup handler needs a bit more logic:

document.onkeyup = event => {
+  const key = event.key;
+  switch (key) {
+    case "d":
+    case "ArrowRight":
+      if (this.shipMovesHorizontal > 0) {
+        this.shipMovesHorizontal = 0;
+      }
+      break;
+    case "a":
+    case "ArrowLeft":
+      if (this.shipMovesHorizontal < 0) {
+        this.shipMovesHorizontal = 0;
+      }
+      break;
+    case "w":
+    case "ArrowUp":
+      if (this.shipMovesVertical < 0) {
+        this.shipMovesVertical = 0;
+      }
+      break;
+    case "s":
+    case "ArrowDown":
+      if (this.shipMovesVertical > 0) {
+        this.shipMovesVertical = 0;
+      }
+      break;
+  }
+};
+
+

Check out the full code at CodeSandbox

Much better, isn't it? Whatever we do, the ship is flying in the expected direction. Time to tackle the last problems. Lets go with the easier one first: Acceleration.

For now, the ship simply has a fixed speed. Lets make it faster first, because we want action, right? For that, we'll define the maximum speed of the ship:

this.shipSpeed = 5  // pixel per frame
+
+

And use it as a multiplicator:

  update() {
+    // move the ship
+    this.shipX += this.shipMovesHorizontal * this.shipSpeed;
+    this.shipY += this.shipMovesVertical * this.shipSpeed;
+
+    /* drawing stuff */
+  }
+
+

And now, instead of jumping to the full speed, we update velocity values per axis:

  constructor () {
+    /* ... */
+    this.shipSpeed = 5
+    this.shipVelocityHorizontal = 0
+    this.shipVelocityVertical = 0
+    /* ... */
+  }
+
+  /* ...more stuff... */
+
+  update () {
+    // accelerate the ship
+    const maxSpeed = this.shipSpeed;
+    // speed can be negative (left/up) or positive (right/down)
+    let currentAbsSpeedH = Math.abs(this.shipVelocityHorizontal);
+    let currentAbsSpeedV = Math.abs(this.shipVelocityVertical);
+
+    // increase ship speed until it reaches maximum
+    if (this.shipMovesHorizontal && currentAbsSpeedH < maxSpeed) {
+      this.shipVelocityHorizontal += this.shipMovesHorizontal * 0.2;
+    } else {
+      this.shipVelocityHorizontal = 0
+    }
+    if (this.shipMovesVertical && currentAbsSpeedV < maxSpeed) {
+      this.shipVelocityVertical += this.shipMovesVertical * 0.2;
+    } else {
+      this.shipVelocityVertical = 0
+    }
+
+    /* drawing stuff */
+  }
+
+

This slowly accelerates the ship until full speed. But it still stops immediately. To decelerate the ship and also make sure the ship actually stops and doesn't randomly float around due to rounding errors, some more lines are needed. You'll find everything in the final version on CodeSandbox.

Now the last problem has be solved: Framerate-dependent movement. For now, all the values are tweaked in a way that they work nicely at the current speed. Lets assume at sixty frames per second. Now that poor computer has to install updates in the background or maybe it is just Chrome getting messy. Maybe the player has a different screen refresh rate. The result is a drop or increase of the frame rate. Lets take a drop down to the half as an example. Thirty frames per second is still completely smooth for almost everything. Movies have thirty frames per second and they do just fine, right? Yet our ship is suddenly only half as fast and that difference is very noticeable.

To prevent this, the movement needs to be based on actual time. Instead of a fixed value added to the coordinates each frame, a value is added that respects the time passed since the last update. The same is necessary for velocity changes. So instead of the more or less arbitrary five pixels at sixty frames per second we set the value in pixels per millisecond because everything is in millisecond precision.

5px*60/s = 300px/s = 0.3px/ms
+
+

This makes the next step rather easy: Count the amount of milliseconds since the last update and multiply it with the maximum speed and acceleration values:

  constructor () {
+    /* ... */
+    this.shipSpeed = 0.3  // pixels per millisecond
+    // how fast the ship accelerates
+    this.shipAcceleration = this.shipSpeed / 10.0
+    this.shipVelocityHorizontal = 0
+    this.shipVelocityVertical = 0
+    /* ... */
+
+    // this should always happen right before the first update call
+    // performance.now gives a high precision time value and is also
+    // used by requestAnimationFrame
+    this.lastDraw = performance.now()
+    requestAnimationFrame(stamp => this.update(stamp))
+  }
+
+  /* ...more stuff... */
+
+  // See the main loop section if "stamp" looks fishy to you.
+  update (stamp) {
+    // calculate how much time passed since last update
+    const timePassed = stamp - this.lastDraw
+    this.lastDraw = stamp
+
+    // accelerate the ship
+    const maxSpeed = this.shipSpeed * timePassed;
+    const accel = this.shipAcceleration * timePassed;
+
+    let currentAbsSpeedH = Math.abs(this.shipVelocityHorizontal);
+    let currentAbsSpeedV = Math.abs(this.shipVelocityVertical);
+
+    if (this.shipMovesHorizontal && currentAbsSpeedH < maxSpeed) {
+      const acceleration = 
+      this.shipVelocityHorizontal += this.shipMovesHorizontal * accel;
+    } else {
+      this.shipVelocityHorizontal = 0
+    }
+    if (this.shipMovesVertical && currentAbsSpeedV < maxSpeed) {
+      this.shipVelocityVertical += this.shipMovesVertical * accel;
+    } else {
+      this.shipVelocityVertical = 0
+    }
+
+    /* drawing stuff */
+  }
+
+

Check out the full version at CodeSandbox

If everything is the same as before you did everything right. Now independent of the frame rate you ship will move five pixels per millisecond. Unfortunately I didn't find a good way to test that except for changing the refresh rate of your screen or overwriting requestAnimationFrame so I left this part out of the post.

The End

Congratulations, you made a fully moving ship. This Post ends here but of course there is so much more to learn about game development. Freddy vs JSON adds some more elements but uses only techniques described in this article. Feel free to check out its source code and create a ton of games like it. Or completely different ones. Be creative and enjoy to use what you've just learned.

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/2020-06-29-a-store-implementation-for-vue3-composition-api/index.html b/zig-out/blog/2020-06-29-a-store-implementation-for-vue3-composition-api/index.html new file mode 100644 index 0000000..dcc34d2 --- /dev/null +++ b/zig-out/blog/2020-06-29-a-store-implementation-for-vue3-composition-api/index.html @@ -0,0 +1,280 @@ + + + + + + the codeartist — programmer and engineer based in BerlinA store implementation from scratch using Vue3's Composition API + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

A store implementation from scratch using Vue3's Composition API

+ I've built a store implementation that allows name-spaced actions and helps with the separation of concerns. The new Composition API in Vue3 also allows completely new, convenient ways of using it. +
+ Last updated: +
+ +

This article is crossposted on dev.to. Feel free to join the discussion there.

At some point I started moving a side project over to Vue3 (which is still in beta). The side project is in a rather early stage and so I decided to rebuild the whole underlying foundation of it from scratch making use of the new possibilities of Vue3, especially of course the composition API.

Nuisance

One nuisance I had was the way I handled state. I didn't use Vuex but instead left state handling to a global state class that I added to Vue like Vue.prototype.$store = new StorageHandler. That allowed me to access global state from everywhere within Vue components via this.$store and worked pretty well in most cases. But when the store grew a bit more complex I wished back some of the features Vuex offers. Especially actions, name-spacing and with them the much better encapsulation of the state. It also adds extra work as soon as you need to access the state from outside Vue, for example in API call logic.

When moving to Vue3 I played with the thought to try Vuex4. It has the same API as Vuex3 and is meant to be usable as a drop-in when updating a Vue2 application to Vue3. But rather quickly I decided to roll my own, simplified implementation that uses the new Composition API because it would make things much neater. But lets quickly recap first what this Composition API is and how it helped me here:

Composition API vs Options API

What is the Composition API and what is the Options API? You might not have heard of those terms yet but they will become more popular within the Vue ecosystem as soon as Vue3 is out of beta.

The Options API is and will be the default way to build components in Vue. It is what we all know. Lets assume the following template:

<div>
+  <div class="greeting">{{ hello }}</div>
+  <input v-model="name" placeholder="change name" />
+
+  <div class="counter">Clicked {{ clicks }} times</div>
+  <button @click="countUp">click!</button>
+</div>
+
+

This is how an Options API example would look like:

const component = new Vue({
+    return {
+      name 'World',
+      clicks: 0
+    }
+  },
+  computed: {
+    hello () {
+      return `Hello ${this.name}`
+    }
+  },
+  methods: {
+    countUp () {
+      this.clicks++
+    }
+  }
+})
+
+

This still works the same in Vue3. But additionally it supports a new setup method that runs before initializing all the rest of the component and provides building blocks. Together with new imports this is the Composition API. You can use it side-by-side or exclusively to create your components. In most cased you'll not need it but as soon as you want to reuse logic or simply split a large component into logical chunks, the Composition API comes in very handy.

Here's one way how the example could look like using setup():

import { defineComponent, computed } from 'vue'
+
+// defineComponent() is now used instead of new Vue()
+const component = defineComponent({
+  setup () {
+    // greeting
+    const name = ref('World')
+    const hello = computed(() => `Hello ${name.value}`)
+    // counting
+    const clicks = ref(0)
+    const countUp = () => clicks.value++
+
+    return { name, hello, clicks, countUp }
+  }
+}  
+
+

Some things here might seem odd. computed gets imported, ref and whyname.value? Isn't that going to be annoying? It would be out of scope for this article, so I better point you to a source that explains all of this much better than I could: composition-api.vuejs.org is the place to go! There are also great courses on VueMastery.

Back to topic: The cool new thing now is that we can group concerns. Instead of putting each puzzle piece somewhere else (that is variables in data, reactive properties in computed and methods in methods) we can create everything grouped next to each other. What makes it even better is that thanks to the global imports, every piece can be split out into separate functions:

// Afraid of becoming React dev? Maybe call it 'hasGreeting' then.
+function useGreeting () {
+  const name = ref('World')
+  const hello = computed(() => `Hello ${name.value}`)
+  return { name, hello }
+}
+
+function useCounting () {
+  const count = ref(0)
+  const countUp = () => count.value = count.value + 1
+  return { count, countUp }
+}
+
+const component = defineComponent({
+  setup () {
+    const { name, hello } = useGreeting()
+    const { count: clicks, countUp } = useCounting()
+    return { name, hello, clicks, countUp }
+  }
+}  
+
+

This works the same way and it works with everything, including computed properties, watchers and hooks. It makes it also very clear where everything is coming from, unlike mixins. You can play around with this example in this Code Sandbox I made.

Minimalist but convenient state handling

While looking at the Composition API I thought about how it could be nice for simple and declarative state handling. Assuming I have somehow name-spaced state collections and actions, a bit like we know from Vuex, for example:

import { ref } from 'vue'
+
+// using 'ref' here because we want to return the properties directly
+// otherwise 'reactive' could be used
+export const state = {
+  name: ref('World'),
+  clicks: ref(0)
+}
+
+export const actions = {
+  'name/change': (name, newName) => {
+    name.value = newName
+  },
+  'clicks/countUp': (clicks) => {
+    clicks.value++
+  }
+}
+
+

Now this is a very simplified example of course but it should illustrate the idea. This could be used directly and the Composition API makes it not too inconvenient alread. Unfortunately it is not exactly beautiful to write (yet):

import { state, actions } from '@/state'
+
+defineComponent({
+  setup () {
+    return {
+      name: state.name,
+      clicks: state.clicks,
+      // brrr, not pretty
+      changeName (newName) { actions['name/change'](state.name, newName) }
+      countUp () { actions['clicks/countUp'](state.clicks) }
+    }
+  }
+})
+
+

To make this not only prettier but also less verbose, a helper can be introduced. The goal is to have something like this:

import { useState } from '@/state'
+
+defineComponent({
+  setup () {
+    const { collection: name, actions: nameActions } = useState('name')
+    const { collection: clicks, actions: clickActions } = useState('clicks')
+
+    return {
+      name,
+      clicks,
+      changeName: nameActions.change
+      countUp: clickActions.countUp
+    }
+  }
+})
+
+

Much nicer! And not too hard to build! Lets have a look at the useState source code:

function useState (prop) {
+  // assumes available state object with properties
+  // of type Ref, eg const state = { things: ref([]) }
+  const collection = state[prop]
+
+  // assumes available stateActions object with properties
+  // in the form 'things/add': function(collection, payload)
+  const actions = Object.keys(stateActions).reduce((acc, key) => {
+    if (key.startsWith(`${prop}/`)) {
+      const newKey = key.slice(prop.length + 1) // extracts action name
+      acc[newKey] = payload => stateActions[key](collection, payload)
+    }
+    return acc
+  }, {})
+
+  return { collection, actions }
+}
+
+

Just ten lines and it makes life so much easier! This returns the collection reference and maps all actions accordingly. For the sake of completeness here a full example with state and stateActions:

import { ref } from 'vue'
+
+// not using reactive here to be able to send properties directly
+const state = {
+  count: ref(0),
+  name: ref('World')
+}
+
+const stateActions = {
+
+  'count/increase' (countRef) {
+    countRef.value++
+  },
+  'count/decrease' (countRef) {
+    countRef.value--
+  },
+
+  'name/change' (nameRef, newName) {
+    nameRef.value = newName
+  }
+
+}
+
+function useState (prop) { /* ... */ }
+
+

Now useState('count') would return the reference state.count and an object with the actions increase and decrease:

import { useState } from '@/state'
+
+defineComponent({
+  setup () {
+    const { collection: count, actions: countActions } = useState('count')
+    return {
+      count,
+      countUp: countActions.increase
+    }
+  }
+})
+
+

This works well for me and happened to be very convenient already. Maybe I'll make a package out of it. What are your opinions on this?

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/blog/index.html b/zig-out/blog/index.html new file mode 100644 index 0000000..b0301c1 --- /dev/null +++ b/zig-out/blog/index.html @@ -0,0 +1,173 @@ + + + + + + the codeartist — programmer and engineer based in BerlinBlog + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Blog

+ Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side. +
+ +
+ +
    +
  1. + + +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    + + + +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    + + + +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    + + + +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    + + + +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    + + +
    + The Magic 0xC2 + (~1 mins) +
    +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    + + + +

    Sometimes, I write long-form articles about a topic that I find interesting. I use this as a way to dive deeper into a topic, while often create an example project on the side.

    +
    2. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/cv/index.html b/zig-out/cv/index.html new file mode 100644 index 0000000..e34916d --- /dev/null +++ b/zig-out/cv/index.html @@ -0,0 +1,114 @@ + + + + + + the codeartist — programmer and engineer based in BerlinCV / Résumé + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

CV / Résumé

+ My Curriculum Vitae / Résumé. I know, there is a difference. This page is technically a résumé, while the whole site would be closer to a CV. +
+ Last updated: +
+ +

In me you will find an enthusiastic, passionate developer with around 13 years of professional experience in and around software development, mainly full-stack web development and consulting, but also coaching and community work. I strive to seek roles in creative, forward thinking companies with diverse teams that offer challenging work, trust and responsibility. Since 2022 I'm the principal frontend engineer and frontend chapter lead of Code Gaia.

Principal Frontend Engineer, Code Gaia

Gode Gaia GmbH, Munich / remote (since August 2022)

Main responsibilities

  • leading the frontend chapter

  • defining development processes and standards

  • team management responsibilities

  • lead complete rewrite of frontend

  • interviewing potential new hires

Key Technologies

  • Javascript/Typescript: Vue3 with Composition API

  • AWS Amplify

  • AWS Bedrock

Noteworthy aspects

  • AI integration (LLM as well as document scanning and categorization)

  • Python / Django backend

  • 100% remote work

Senior Software Engineer, Coursedog

Coursedog Inc, New York / remote (June 2021 till June 2022)

Main responsibilities

  • frontend introduction and contact for newcomers

  • maintainance/bug fixing for existing features

  • development of multiple new features

  • introduced Docker to ease developer onboarding

  • lead the frontend-part of feature flags introduction

  • being part of the Typescript transition team

Key Technologies

  • Javascript/Typescript: Vue2 with Composition API

  • Node: Express, Fastify

Noteworthy aspects

  • Large codebase (~450k SLOC in total)

  • 100% remote work

Senior Consultant, Wunderdog

Wunderdog GmbH, Helsinki / Berlin / remote (June 2018 till June 2021)

Main responsibilities

  • Consultant work with lots of different clients

  • including leadership roles, hiring and building new teams

  • enhancing existing teams or on my own

  • in companies ranging from 1000s of employees to small startups

  • sectors include retail, sports, travel, entertainment, HR

  • doing feature development for large, medium and small as well as greenfield projects

Key Technologies

  • Javascript/Typescript: Vue, React, Ember

  • Node: Express, Koa, Featherjs

  • Ruby: Ruby on Rails, Sinatra

  • AWS, GCP

Noteworthy aspects

  • Wide variety of projects and companies

  • Greenfield projects as well as existing code bases

Senior Software Engineer, HERE

HERE Global BV, Berlin (November 2017 till March 2018)

Main responsibilities

  • planning and implementation of a web based floor plan and indoor navigation system with touch controls and full access control system

  • integration of meeting room related functionality into Office 365

Key Technologies

  • Javascript: Vue, SVG, MapGL

  • Node: Express

  • IOT: Bluetooth controlled sensors

  • Azure Cloud and Microsoft Office 365 integration

Senior Software Engineer, FromAtoB

FromAtoB GmbH, Berlin (August 2016 till September 2017)

Main responsibilities

  • development of a single-page application in the travel sector

  • lead the introduction of Vue into the process

  • rebuilt complete website funnel and replaced old application step-by-step

  • while maintaining the Ruby-on-Rails based web application

  • implemented internal tooling in Rust

Key Technologies

  • Javascript/Typescript (Vuejs)

  • Ruby (Ruby on Rails)

  • Rust

Software Engineer (freelancing)

Berlin, remote (June 2015 till August 2017)

Clients (selection)

  • Zalando (Retail, frontend-development with React)

  • Camunda (BPMN.io, open-source web-based BPMN modeler and rendering toolkit, Javascript, SVG)

  • Blacklane (Ride service, web-based booking system, AngularJS, Node Express)

Key Technologies

  • Javascript/Typescript: Vue, React, AngularJS

  • Node: Express

Software Engineer, HERE

HERE Global BV, Berlin (November 2013 till May 2015)

Main responsibilities

  • implementation of a mapping and discovery web-application

  • map-tile loading optimization

  • path rendering

  • POI proximity search

Key Technologies

  • Javascript/Typescript: Vue, React, Ember

  • Node: Express, Koa, Featherjs

  • Ruby: Ruby on Rails, Sinatra

Software Engineer (freelancing)

Leipzig, Berlin, remote (October 2009 till October 2013)

Clients (selection)

  • Coreon (Taxonomy management, web-based editor, Javascript, Backbone, SVG, Ruby on Rails)

  • Wimdu (Travel web-application, live search, Javascript, Backbone, Ruby on Rails, ElasticSearch

  • Appzonaut / Telekom Innovation Labs (experimental UI for multi-cloud management, Javascript, Backbone, SVG, Python, Flask

Key Technologies

  • Javascript: Backbone, AngularJS

  • Ruby: Ruby on Rails, Sinatra / Padrino

  • Python: Flask

  • SVG, HTML5, CSS3

  • CouchDB, MongoDB

+ +
+ +
+ + +
+ +
+ + + + diff --git a/dist/fediverse.svg b/zig-out/fediverse.svg similarity index 100% rename from dist/fediverse.svg rename to zig-out/fediverse.svg diff --git a/dist/gitforge.svg b/zig-out/gitforge.svg similarity index 100% rename from dist/gitforge.svg rename to zig-out/gitforge.svg diff --git a/dist/github.svg b/zig-out/github.svg similarity index 100% rename from dist/github.svg rename to zig-out/github.svg diff --git a/dist/header.jpg b/zig-out/header.jpg similarity index 100% rename from dist/header.jpg rename to zig-out/header.jpg diff --git a/zig-out/index.html b/zig-out/index.html new file mode 100644 index 0000000..e37c256 --- /dev/null +++ b/zig-out/index.html @@ -0,0 +1,157 @@ + + + + + + the codeartist — programmer and engineer based in BerlinWelcome + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+ Hi there! I am a + programmer, + open-source + enthusiast + and + hacker + based in Berlin, Germany. +

+

+ I call myself a code artist, because programming can and should be seen as a creative process; therefore code is + art. I love to craft pieces of art with code, that are beautiful and elegant in their simplicity, readability + and architecture. +

+

+ Looking for expert advice and development services for a short-term project? I offer guidance on software + architecture decisions, coding solutions and performance optimizations tailored to your needs. Let's work + together to solve your challenges. + Get in touch! +

+ + +
+ +

experience

Thirteen years of professional experience in a couple of tweets

Pretty early in my life I realized that I work best on my own terms. That does not mean that I prefer to work alone. Working with clients, team mates, designers and managers is a crucial part of any development process.

Some time in the year 2009 I decided to not only live up to my way of working but also share my experience even more. I decided to become a freelancing programmer and consultant. Since then many different places benefited from my work. Start-Ups in their first months as well as well known companies like HERE and Deutsche Telekom Labs.

Together with entrepreneurs, UI/UX experts and engineers of many fields I created novel and beautiful applications that still influence the live of thousands of people.

Please see my CV for a more detailed list.

coaching

Whenever possible, I try to help others to learn

I’m the organizer of Vuejs // Berlin, a monthly meetup group around Vue and web technologies in general.

Many people want to learn and grow. Whenever I can I try to help those people by sharing my experience and knowledge. I already voluntarily coached at Code Curious, Frauenloop and Jugend Hackt. I also helped children with their first steps into the world of programming at the Berlin CoderDojo.

contact

You can find me all over the interwebs

+
+ + + +
+ +
+ + +
+ + +
+ + + + diff --git a/dist/instagram.svg b/zig-out/instagram.svg similarity index 100% rename from dist/instagram.svg rename to zig-out/instagram.svg diff --git a/dist/linkedin.svg b/zig-out/linkedin.svg similarity index 100% rename from dist/linkedin.svg rename to zig-out/linkedin.svg diff --git a/dist/mail.svg b/zig-out/mail.svg similarity index 100% rename from dist/mail.svg rename to zig-out/mail.svg diff --git a/dist/mastodon.svg b/zig-out/mastodon.svg similarity index 100% rename from dist/mastodon.svg rename to zig-out/mastodon.svg diff --git a/zig-out/now/index.html b/zig-out/now/index.html new file mode 100644 index 0000000..cc708e7 --- /dev/null +++ b/zig-out/now/index.html @@ -0,0 +1,114 @@ + + + + + + the codeartist — programmer and engineer based in BerlinNow + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Now

+ This page shows what I'm up to at the moment, following the idea of Derek Sivers. +
+ Last updated: +
+ +

You can find more now pages on nownownow.

Still live in Berlin where I am working fully remote. I'm approaching the second anniversary at Code Gaia now and have no plans to change any of it.

Priorities

I do a lot of things all the time and have a hard time to focus. Most of my energy right now hopefully flows into the following things:

  • This homepage.

  • Keeping up the pace professionally by taking up more management responsibilities.

  • Ramping up my side-project game (mainly by doing smaller freelancing jobs).

  • Fleshing out a long form D&D campaign ("Out Of The Cold Shadow").

  • Writing down more short adventures and one-shots and publish them on tiskifer.dk.

  • My wedding and honeymoon in June!

Book(s)

I'm not really good with taking time for reading, but when I do, I read:

Accelerando by Charles Stross

The Manager's Path by Camille Fournier

+ +
+ +
+ + +
+ +
+ + + + diff --git a/dist/posts.css b/zig-out/posts.css similarity index 56% rename from dist/posts.css rename to zig-out/posts.css index 135b44c..e8186a0 100644 --- a/dist/posts.css +++ b/zig-out/posts.css @@ -1,7 +1,3 @@ -main.posts { - margin: calc(var(--header-height-small) + 4rem) auto 4rem; -} - main.posts h2 { margin: 1.5em 0 0 0; font-size: 1.5rem; @@ -25,16 +21,3 @@ main.posts article>div>a.external, main.posts article>div>.reading-time { color: gray; } - -hr { - display: block; - border: none; - width: 100%; - height: 1px; - margin: 2rem 0; - background-color: var(--emboss-color); -} - -span[title] { - text-decoration: underline wavy gray; -} \ No newline at end of file diff --git a/zig-out/projects/index.html b/zig-out/projects/index.html new file mode 100644 index 0000000..5db5356 --- /dev/null +++ b/zig-out/projects/index.html @@ -0,0 +1,114 @@ + + + + + + the codeartist — programmer and engineer based in BerlinProjects + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Projects

+ My currently active projects. This is mostly about software, but might also include some TTRPG stuff, from time to time. +
+ Last updated: +
+ +

Homepage Overhaul

With lots of work comes lots of opportunity for productive procrastination

Not too long ago, .ing TLDs became available, that allowed me to finally have my full name as a "cool" domain name: koehr.ing. Other domains I have are nkoehring.de (boring), koehr.in (confusing) and k0r.in (nerdy). koehri.ng wouldn't be possible due to domain registars policies or pricing (Nigeria used to have the british model, like allowing only net.ng, com.ng, and so on. Later they allowed more, but the price would be pretty high).

Why am I writing all this? Because the new domain name made me think about my homepage as a professional. I wanted to have something, that showcases my skills while not being the usual boring homepage. This is how the interactive homepage experiment began; a terminal like website, written from scratch. Having this, I now also needed to change my old homepage to somehow feature my new shiny experiment. But my old homepage is white and not very responsive; two very good reasons (for me), to change it. So I also started writing a completely new homepage, using vss. Pretty soon I realised, it is by far not mature enough for my needs, so I started building workarounds to suit my needs, so I don't get stuck in the rabbit hole of choosing frameworks over finishing the page. My plan is, to finish the page and its content and then, when there is time, move it on top of something more sophisticated, like good ol' Zola.

New Server

I found a pretty cheap dedicated server with tons of space and quite some CPU power, compared to cheap virtual servers. Now I need to move everything I hosted on a VServer before. That is not a simple task, unfortunately, as I tend to overthink and want to use the change to make everything better (or just different, maybe). This move includes a switch from Docker and systemd services to podman and lingering users. This way, no root enabled service is involved in running any outside-facing services. This website and everything under the koehr.ing domain runs already on the new server.

learned.today

Quite a while (aka way too long) ago, I bought the domain learned.today and thought about some idea around a Today I learned page or service, where people just share short snippets of things they just learned, similar to my TIL page. I never got to implementing it though. I wrote it down here as a motivation for myself, to finally work on it.

+ +
+ +
+ + +
+ +
+ + + + diff --git a/dist/reddit.svg b/zig-out/reddit.svg similarity index 100% rename from dist/reddit.svg rename to zig-out/reddit.svg diff --git a/dist/rubik-regular-minimal.woff2 b/zig-out/rubik-regular-minimal.woff2 similarity index 100% rename from dist/rubik-regular-minimal.woff2 rename to zig-out/rubik-regular-minimal.woff2 diff --git a/zig-out/setup/index.html b/zig-out/setup/index.html new file mode 100644 index 0000000..9030339 --- /dev/null +++ b/zig-out/setup/index.html @@ -0,0 +1,114 @@ + + + + + + the codeartist — programmer and engineer based in BerlinSetup + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Setup

+ As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use. +
+ Last updated: +
+ +

This page focusses on Hardware. For Software, check /stack.

I used to work on laptops without any extras, but over the years ergonomics got more and more important. Now I have a second screen, a standing desk and an ergonomic chair. My main keyboard is split in half and my pointer device is a big red ball.

Work Computer: Thinkpad T14s

Decent CPU, good amount of RAM, very lightweight, great battery life

Thinkpads are my go-to laptops for work. They are robust and performant.

Private Computer: ASUS Zenbook Pro Duo

Fantastic screen, a second display, decent hardware

My private laptop is a bit more experimental. It features a dual screen setup with a 16:10 OLED screen and an additional 16:5(-ish) LCD above the keyboard.

Keyboard: Sofle 2 split-keyboard

I use the Sofle 2 keyboard. I adapted it to my needs. It features two rotary encoders and a customized qmk firmware configuration. The source code can be found on github.

Pointer: Kensington Orbit

The Kensington Orbit is a trackball and a treat for every wrist.

Desk: ergonomic

My desk is height adjustable, so that I can sit or stand at it. Its not a fancy branded one; it does it job well, though.

Chair: ergonomic

My chair is an ergonomic office chair with 4D arm rests and extra back support. I can sit on it all day without issues.

+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/stack/index.html b/zig-out/stack/index.html new file mode 100644 index 0000000..ed7866c --- /dev/null +++ b/zig-out/stack/index.html @@ -0,0 +1,114 @@ + + + + + + the codeartist — programmer and engineer based in BerlinStack + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Stack

+ As a software engineer, the tools I use define how I work and I find it inspiring to see which tools other people use. +
+ Last updated: +
+ +

This page focusses on Software. For Hardware, check /setup.

My software stack is pretty old-school. I prefer CLI applications for almost everything. The only GUI programs I usually run are browsers, image manipulators and LogSeq.

OS: Fedora Linux

It all started with Real Red Linux 2000, a special millenium version of RedHat Linux. I don't know for sure, but I think it was based on RedHat 6.1 or 6.2.

Over the years, I first used different RPM based distributions, then switched to Gentoo for a while, before getting annoyed by the compiling frenzy and discovering Arch. When Arch made the switch to systemd, I found Void Linux and stayed with it for years. At some point, not many years ago, I went with Fedora and it struck a nice middle ground between customizability and "it just works". Thanks to Fedora Spins, it is now easy to have a more standard system on my work laptop and a rather customized one on my private laptop, without too many differences in the foundation. I use official the Sway Spin on my private laptop.

DE: GNOME vs Sway

Over the years I got used to tiling window managers. Honestly, I tried almost all of them and went from hyper-configurable to super minimalist. I ended up - as usual - somewhere in the middle, with i3 and Sway.

My work laptop has a GNOME desktop with some extensions, that make it work well for me. My typical work flow involves full screen applications and many desktops. I rarely have more than one window on one screen. That is why I didn't have too much of a hard time to switch from dwm and similar tiling window managers to GNOME, because it uses MacOS-like gestures to work with desktops. Extensions like Maximize Lonely Window help as well. There used to be another extension, Maximize To Empty Workspace, which was even closer to my usual way of working. But it is not supported in newer GNOME versions.

Editor: Helix

Most of my life, I used ViM. It made me more productive and helped me to focus on the things that matter most for my productivity. One day, I found Kakoune, which blew me away by being so similar and yet different to ViM, in a (in my opinion) good way. What Kakoune does is to to switch around the command order. While ViM's command language is VERB-MODIFIER-OBJECT. For example: d2w means delete two words. Kakoune switches that to MODIFIER-VERB-OBJECT and introduces selecting and non-selecting movement, which allows you to see your selection before applying an action. d2w changes to 2Wd, which translates to select next two words, then delete them. I finally settled with Helix, an editor that uses Kakounes command language, but implements many useful things by default, while still being very configurable.

Terminal: foot + zellij + zsh

Almost all of my day-to-day applications are in the terminal. I am so used to it, that I started trusting GUI applications less. This is obviously my issue, but luckily I'm not alone, so many great CLI applications exist.

I use foot as terminal emulator. It is lightweight, supports 24bit colours and works with Wayland.

Inside foot runs zellij, which is a terminal multiplexer similar to screen and tmux. It allows me to run multiple applications in one terminal, keeps sessions alive after closing the terminal emulator and so on. I actually configured zellij to feel a lot more like tmux, because I'm so used to the latter and honestly I might just switch back to tmux, who knows.

My shell of choice is zsh with oh-my-zsh. It is by far the most versatile shell and the only one (to my knowledge) that supports RPROMPT, a prompts at the end of the line.

Browser: Firefox

My browser of choice is Firefox, because I want an open and diverse internet. Firefox is a great choice and offers lots of features, like direct PDF support, privacy features out of the box and great synchronisation. Chrome and Chromium-based browsers are great as well, but if everyone uses the same browser, we'll end up with whatever the company behind this browser wants the internet to be.

Other Tools: LogSeq, Poe, Bitwarden, Git...

Of course, I use a lot more tools in my day-to-day work.

I use LogSeq for knowledge management. It is similar to Evernote, Obsidian or Notion. For me it hits the mark between flexibility and structure. I use it for everthing from todo lists to planning long D&D campaigns.

Poe allows access to all kinds of generative intelligence tools, like LLMs ("ChatGPT") and image generators. I mostly use Mistral, but also switch between models from time to time. They help me with brainstorming and sometimes I misuse them to write JSDoc comments for me.

Bitwarden is a fantastic password manager with lots of utilities. It works so that you don't need to trust the server provider, because everything runs on the client (for example in a browser plugin) and is encrypted locally before being sent to the server. The best thing is, that I can host a bitwarden server myself, using Vaultwarden.

GIT is the most widely used source code management as of today. Although I see some strengths in other systems, Git is by far good enough for all my needs. I host my own Forgejo git server at git.k0r.in.

There is a lot more and I might extend this list from time to time.

+ +
+ +
+ + +
+ +
+ + + + diff --git a/dist/style.css b/zig-out/style.css similarity index 72% rename from dist/style.css rename to zig-out/style.css index 5c5d9e1..d51167c 100644 --- a/dist/style.css +++ b/zig-out/style.css @@ -53,6 +53,44 @@ body { scroll-behavior: smooth; } +#main-menu { + position: fixed; + top: var(--header-height); + width: 100vw; + background-color: var(--menu-bg-color); + transition: top .3s ease-in-out, background-color 1s ease-in; +} + +#main-menu>menu { + width: 960px; + max-width: 98%; + height: 1.2rem; + margin: 0 auto 0; + padding: 0; + display: flex; + justify-content: space-around; + align-items: center; + list-style: circle; +} +#main-menu > li { + padding: 0; +} +body>header.small + #main-menu { + top: var(--header-height-small); + background-color: var(--header-bg-color); +} +body>header.small + #main-menu>menu { + padding: .5rem 0; +} +pre { + background: var(--emboss-color); + padding: .5rem; +} +li.active>a { + color: var(--highlight-fg-color); + font-weight: bold; +} + body>#spacer, body>header { position: fixed; @@ -66,7 +104,7 @@ body>#spacer { height: var(--header-height-small); } -body>header { +body>header, body>header>a { height: var(--header-height); color: transparent; transition: transform .3s ease-in-out; @@ -77,7 +115,7 @@ body>header.small { transform: scale(var(--header-height-multiplier)); } -body>header>svg { +body>header svg { display: block; width: 960px; max-width: 98vw; @@ -91,6 +129,11 @@ body>main { margin: var(--header-height) auto 4rem; } +body>main>header { + display: block; + padding: 2em 0; +} + a { color: var(--page-fg-color); } @@ -117,7 +160,7 @@ code { padding-top: 2rem; } #content>h1, -main.posts > header > h1 { +main > header > h1 { margin: 0 0 .25em; font-size: 2rem; font-variant: small-caps; @@ -127,6 +170,9 @@ main.posts > header > h1 { #content>h1 { padding-top: 2em; } +h2 { + color: var(--highlight-fg-color); +} #cta { display: flex; @@ -203,6 +249,19 @@ main.posts > header > h1 { animation: fade 2s linear infinite; } +hr { + display: block; + border: none; + width: 100%; + height: 1px; + margin: 2rem 0; + background-color: var(--emboss-color); +} + +span[title] { + text-decoration: underline wavy gray; +} + @keyframes fade { 0% { opacity: 1.0; @@ -239,6 +298,25 @@ main.posts > header > h1 { } @media (max-width: 480px) { + body>header.small { + transform: none; + } + body>header.small + #main-menu { + top: var(--header-height); + } + #main-menu>menu { + height: 2.4rem; + margin-left: 1.5rem; + padding: .5rem 0; + flex-flow: column wrap; + align-items: flex-start; + } + body>main { + margin: calc(var(--header-height) + 2rem) auto 4rem; + } + #content > h1 { + padding-top: calc(var(--header-height) + 2rem); + } .contacts { columns: 1; } diff --git a/dist/threads.svg b/zig-out/threads.svg similarity index 100% rename from dist/threads.svg rename to zig-out/threads.svg diff --git a/zig-out/til/2021-08-31/index.html b/zig-out/til/2021-08-31/index.html new file mode 100644 index 0000000..21cc81c --- /dev/null +++ b/zig-out/til/2021-08-31/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in BerlinThere is a HTML tag for "Word Break Opportunity" + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

There is a HTML tag for "Word Break Opportunity"

+ +
+ Last updated: +
+ +

For example: Kauf<wbr/>haus.

+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2021-09-03/index.html b/zig-out/til/2021-09-03/index.html new file mode 100644 index 0000000..7bd3120 --- /dev/null +++ b/zig-out/til/2021-09-03/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in BerlinBush refused offer to discuss Osama Bin Laden handover + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Bush refused offer to discuss Osama Bin Laden handover

+ +
+ Last updated: +
+ +
+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2021-09-04/index.html b/zig-out/til/2021-09-04/index.html new file mode 100644 index 0000000..8e83f51 --- /dev/null +++ b/zig-out/til/2021-09-04/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in Berlingit fetch repo_url remote_branch:new_local_branch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

git fetch repo_url remote_branch:new_local_branch

+ +
+ Last updated: +
+ +

git fetch $repo_url $remote_branch:$new_local_branch

+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2021-09-05/index.html b/zig-out/til/2021-09-05/index.html new file mode 100644 index 0000000..000651b --- /dev/null +++ b/zig-out/til/2021-09-05/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in BerlinE-Mail that isn't spam is called ham! + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

E-Mail that isn't spam is called ham!

+ +
+ Last updated: +
+ +
+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2022-02-22/index.html b/zig-out/til/2022-02-22/index.html new file mode 100644 index 0000000..f1c47d6 --- /dev/null +++ b/zig-out/til/2022-02-22/index.html @@ -0,0 +1,153 @@ + + + + + + the codeartist — programmer and engineer based in BerlinAdding aliases in vite with typescript needs the same alias in tsconfig + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Adding aliases in vite with typescript needs the same alias in tsconfig

+ +
+ Last updated: +
+ +

For example:

The following vite.config.ts:

import { fileURLToPath, URL } from "url"
+import { defineConfig } from 'vite'
+import vue from '@vitejs/plugin-vue'
+
+// https://vitejs.dev/config/
+export default defineConfig({
+  plugins: [vue()],
+  resolve: {
+    alias: {
+      "~": fileURLToPath(new URL("./src", import.meta.url)),
+      "~component": fileURLToPath(new URL("./src/components", import.meta.url)),
+      "~composable": fileURLToPath(new URL("./src/composables", import.meta.url)),
+      "~lib": fileURLToPath(new URL("./src/lib", import.meta.url)),
+    }
+  }
+})
+
+

will need this in tsconfig.json:

{
+  "compilerOptions": {
+    "paths": {
+      "~/*": [ "./src/*" ],
+      "~component/*": [ "./src/components/*" ],
+      "~composable/*": [ "./src/composables/*" ],
+      "~lib/*": [ "./src/lib/*" ]
+    }
+  }
+}
+
+

The asterixes in the syntax are important (alias/* => ./path/*).

+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2022-03-22/index.html b/zig-out/til/2022-03-22/index.html new file mode 100644 index 0000000..a5043cd --- /dev/null +++ b/zig-out/til/2022-03-22/index.html @@ -0,0 +1,127 @@ + + + + + + the codeartist — programmer and engineer based in BerlinThere is a file system for EFI vars now + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

There is a file system for EFI vars now

+ +
+ Last updated: +
+ +

On kernel updates I saw a recurring "EFI variables are not supported on this system", so I investigated and learned that the new EFI variables are provided via a file system that needs to be mounted first:

mount -t efivarfs efivarfs /sys/firmware/efi/efivars
+
+
+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2022-03-28/index.html b/zig-out/til/2022-03-28/index.html new file mode 100644 index 0000000..d112dd0 --- /dev/null +++ b/zig-out/til/2022-03-28/index.html @@ -0,0 +1,128 @@ + + + + + + the codeartist — programmer and engineer based in Berlinpwdx command shows the working path of a process + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

pwdx command shows the working path of a process

+ +
+ Last updated: +
+ +

For example:

% pwdx 1984
+> 1984: /home/george/ttlctrl
+
+
+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2022-04-25/index.html b/zig-out/til/2022-04-25/index.html new file mode 100644 index 0000000..b7bf30c --- /dev/null +++ b/zig-out/til/2022-04-25/index.html @@ -0,0 +1,144 @@ + + + + + + the codeartist — programmer and engineer based in BerlinJest mocks are ...different + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Jest mocks are ...different

+ +
+ Last updated: +
+ +

If you want to mock an imported function in Jest in a way that allows you to check if it has been called, you can not do the seemingly straighforward:

// mock prefix necessary btw
+const mockThatFunction = jest.fn(() => 'stuff')
+
+jest.mock('@/path/to/module', () => ({
+  thatFunction: mockThatFunction,
+}))
+
+// ...in test descriptions
+expect(mockThatFunction).toHaveBeenCalled()
+
+

This way thatFunction will be undefined without anyone telling you why.

What you need to do instead:

import { thatFunction } from '@/path/to/module'
+
+jest.mock('@/path/to/module', () => ({
+  thatFunction: jest.fn(() => 'stuff'),
+}))
+
+// ...in test descriptions
+expect(thatFunction).toHaveBeenCalled()
+
+
+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2022-06-15/index.html b/zig-out/til/2022-06-15/index.html new file mode 100644 index 0000000..7b5a0a2 --- /dev/null +++ b/zig-out/til/2022-06-15/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in BerlinDisallowed Focussed Tests and how it saved my day + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Disallowed Focussed Tests and how it saved my day

+ +
+ Last updated: +
+ +

Today I was about to push a focussed test. A focussed test, you ask?

In Jest (and others) one can run only a specific test, by writing it.only(.... Pushing this to production might create some funny or not so funny side effects though. Luckily there is the no-focussed-tests linter rule in eslint-plugin-jest.

+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2024-05-11/index.html b/zig-out/til/2024-05-11/index.html new file mode 100644 index 0000000..db17813 --- /dev/null +++ b/zig-out/til/2024-05-11/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in BerlinRob Pike's 5 Rules of Programming + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Rob Pike's 5 Rules of Programming

+ +
+ Last updated: +
+ +

  1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

  2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

  3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

  4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

  5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Ken Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.". Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".

+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2024-05-12/index.html b/zig-out/til/2024-05-12/index.html new file mode 100644 index 0000000..e82ce07 --- /dev/null +++ b/zig-out/til/2024-05-12/index.html @@ -0,0 +1,129 @@ + + + + + + the codeartist — programmer and engineer based in BerlinSort list of strings in Javascript + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Sort list of strings in Javascript

+ +
+ Last updated: +
+ + 
users.sort((a, b) => a.firstname.localeCompare(b.firstname))
+
+

or reversed order:

users.sort((a, b) => a.firstname.localeCompare(b.firstname) * -1)
+
+
+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/2024-05-13/index.html b/zig-out/til/2024-05-13/index.html new file mode 100644 index 0000000..fe5e489 --- /dev/null +++ b/zig-out/til/2024-05-13/index.html @@ -0,0 +1,125 @@ + + + + + + the codeartist — programmer and engineer based in BerlinReading speed is usually from 100 to 260 words per minute + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Reading speed is usually from 100 to 260 words per minute

+ +
+ Last updated: +
+ +

With an average of 183 wpm.

+ +
    +
  1. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/zig-out/til/index.html b/zig-out/til/index.html new file mode 100644 index 0000000..7dc61d0 --- /dev/null +++ b/zig-out/til/index.html @@ -0,0 +1,197 @@ + + + + + + the codeartist — programmer and engineer based in BerlinToday I Learned + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Today I Learned

+ This page contains short notes and sometimes code snippets, of interesting things I just found out. +
+ Last updated: +
+ +
+ +
    +
  1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    2. +
+ +
+ +
+ + +
+ +
+ + + + diff --git a/dist/twitter.svg b/zig-out/twitter.svg similarity index 100% rename from dist/twitter.svg rename to zig-out/twitter.svg