From bc650f5bf1005bb3f9a9e51289ef58620e6e6533 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Norman=20K=C3=B6hring?= Date: Mon, 13 May 2024 17:52:03 +0200 Subject: [PATCH] blog --- bin/blog.ts | 97 +++ ...-12-04-the-price-to-crack-your-password.md | 138 ++++ blog/2017-04-09-the-magic-0xc2.md | 61 ++ ...017-08-17-vuejs-reactivity-from-scratch.md | 140 ++++ .../2019-01-10-running-write-freely-on-arm.md | 148 ++++ ...se-openbsds-spleen-bitmap-font-in-linux.md | 36 + blog/2019-05-03-freddy-vs-json.md | 743 ++++++++++++++++++ ...implementation-for-vue3-composition-api.md | 244 ++++++ blog/index.md | 76 +- build.sh | 3 + ...2-04-the-price-to-crack-your-password.html | 383 +++++++++ dist/blog/2017-04-09-the-magic-0xc2.html | 121 +++ ...7-08-17-vuejs-reactivity-from-scratch.html | 152 ++++ ...019-01-10-running-write-freely-on-arm.html | 195 +++++ ...-openbsds-spleen-bitmap-font-in-linux.html | 107 +++ dist/blog/2019-05-03-freddy-vs-json.html | 672 ++++++++++++++++ ...plementation-for-vue3-composition-api.html | 275 +++++++ dist/blog/index.html | 73 +- dist/cv/index.html | 2 +- dist/index.html | 2 +- dist/now/index.html | 2 +- dist/posts.css | 8 +- dist/projects/index.html | 2 +- dist/setup/index.html | 2 +- dist/stack/index.html | 2 +- dist/til/2021-08-31.html | 2 +- dist/til/2021-09-03.html | 2 +- dist/til/2021-09-04.html | 2 +- dist/til/2021-09-05.html | 2 +- dist/til/2022-02-22.html | 2 +- dist/til/2022-03-22.html | 2 +- dist/til/2022-03-28.html | 2 +- dist/til/2022-04-25.html | 2 +- dist/til/2022-06-15.html | 2 +- dist/til/2024-05-12.html | 2 +- dist/til/2024-05-13.html | 83 ++ dist/til/index.html | 9 +- static/posts.css | 8 +- til/2024-05-13.md | 5 + til/index.md | 8 + 40 files changed, 3775 insertions(+), 42 deletions(-) create mode 100644 bin/blog.ts create mode 100644 blog/2016-12-04-the-price-to-crack-your-password.md create mode 100644 blog/2017-04-09-the-magic-0xc2.md create mode 100644 blog/2017-08-17-vuejs-reactivity-from-scratch.md create mode 100644 blog/2019-01-10-running-write-freely-on-arm.md create mode 100644 blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md create mode 100644 blog/2019-05-03-freddy-vs-json.md create mode 100644 blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md create mode 100755 build.sh create mode 100644 dist/blog/2016-12-04-the-price-to-crack-your-password.html create mode 100644 dist/blog/2017-04-09-the-magic-0xc2.html create mode 100644 dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html create mode 100644 dist/blog/2019-01-10-running-write-freely-on-arm.html create mode 100644 dist/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.html create mode 100644 dist/blog/2019-05-03-freddy-vs-json.html create mode 100644 dist/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.html create mode 100644 dist/til/2024-05-13.html create mode 100644 til/2024-05-13.md diff --git a/bin/blog.ts b/bin/blog.ts new file mode 100644 index 0000000..d4fdbb5 --- /dev/null +++ b/bin/blog.ts @@ -0,0 +1,97 @@ +#!/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/blog/2016-12-04-the-price-to-crack-your-password.md b/blog/2016-12-04-the-price-to-crack-your-password.md new file mode 100644 index 0000000..c381a1a --- /dev/null +++ b/blog/2016-12-04-the-price-to-crack-your-password.md @@ -0,0 +1,138 @@ +# 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). + + + +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. + +## 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](https://xkcd.com/936/). + +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: + +* [hashcat benchmark for p2.16xlarge](https://medium.com/@iraklis/running-hashcat-in-amazons-aws-new-16-gpu-p2-16xlarge-instance-9963f607164c#.bzyi0ystz) +* [hashcat benchmark for sagitta brutalis](https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40) + +## 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) + +hash | Amazon | Brutalis | price 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') + +hash | Amazon | Brutalis | price 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') + +hash | Amazon | Brutalis | price 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](https://en.wikipedia.org/wiki/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: + +* [The fastest bruteforce password cracker](http://hashcat.net/hashcat/) +* [More about password cracking methods](https://www.praetorian.com/blog/statistics-will-crack-your-password-mask-structure) +* [Password hashing competition](https://password-hashing.net/) +* [Random word generator for long but memorisable passwords](https://www.randomlists.com/random-words) diff --git a/blog/2017-04-09-the-magic-0xc2.md b/blog/2017-04-09-the-magic-0xc2.md new file mode 100644 index 0000000..ffc51e0 --- /dev/null +++ b/blog/2017-04-09-the-magic-0xc2.md @@ -0,0 +1,61 @@ +# 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](https://news.ycombinator.com/item?id=14089827) + diff --git a/blog/2017-08-17-vuejs-reactivity-from-scratch.md b/blog/2017-08-17-vuejs-reactivity-from-scratch.md new file mode 100644 index 0000000..1d1a67d --- /dev/null +++ b/blog/2017-08-17-vuejs-reactivity-from-scratch.md @@ -0,0 +1,140 @@ +# 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](https://web.archive.org/web/20190113013559/https://log.koehr.in/2017/08/17/vuejs-reactivity-from-scratch) + + + +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](http://www.ecma-international.org/ecma-262/5.1/) JavaScript got lots of exciting new features. Some of them highly underrated and underused in my opinion. [Getters and setters](http://www.ecma-international.org/ecma-262/5.1/#sec-8.6.1) are an example. If you never heard of them, I would recommend you to read [John Riesigs piece](https://johnresig.com/blog/javascript-getters-and-setters/) 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](https://jsfiddle.net/koehr/e2q9vme3/15/). + +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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty). + +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](https://vuejs.org/v2/guide/list.html#Caveats) 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](https://github.com/vuejs/vue/blob/dev/src/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](https://jsfiddle.net/koehr/e2q9vme3/15/), 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](https://github.com/vuejs/vue/blob/dev/src/core/observer/index.js#L140). diff --git a/blog/2019-01-10-running-write-freely-on-arm.md b/blog/2019-01-10-running-write-freely-on-arm.md new file mode 100644 index 0000000..48a7007 --- /dev/null +++ b/blog/2019-01-10-running-write-freely-on-arm.md @@ -0,0 +1,148 @@ +# 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](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. + + + +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/)). + +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 +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: + +```bash +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: + +```sh +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: + +```bash +# 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: + +```bash +# 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/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md b/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md new file mode 100644 index 0000000..6c9fe7f --- /dev/null +++ b/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.md @@ -0,0 +1,36 @@ +# 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). + + + +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: + +```sh +# 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/blog/2019-05-03-freddy-vs-json.md b/blog/2019-05-03-freddy-vs-json.md new file mode 100644 index 0000000..4415112 --- /dev/null +++ b/blog/2019-05-03-freddy-vs-json.md @@ -0,0 +1,743 @@ +# 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](https://github.com/collections/javascript-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](https://wunder.dog)). The [result can be found on Github](https://github.com/nkoehring/FreddyvsJSON). 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](https://github.com/nkoehring/FreddyvsJSON/raw/master/screenshot.jpg) + +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: + +```js +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: + +```html + + +``` + +This works but of course some styling would be great. And maybe having a title? Check out a [complete version on Github](https://github.com/nkoehring/FreddyvsJSON/blob/master/index.html). + +Initializing a Canvas is also pretty simple. Inside `app.js` following lines are necessary: + +```js +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](http://en.wikipedia.org/wiki/Big_ball_of_mud) it is common to use a [state machine](https://en.wikipedia.org/wiki/Finite-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](https://en.wikipedia.org/wiki/Enumerated_type). Here some code to illustrate the idea. The code uses some rather new language features: [Symbols](https://developer.mozilla.org/en-US/docs/Glossary/Symbol) and [Computed Property Names](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#Computed_property_names). + +```js +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: + +```js +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](https://softwareengineering.stackexchange.com/questions/148108/why-is-global-state-so-evil). + +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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals). + + +```js +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: + +```js +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](https://jsperf.com/nested-and-flat-property-access/1) 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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions). + +Typical approaches to run a function in an regular interval would include the usage of `setInterval`: + +```js +let someValue = 23 +setInterval(() => { + someValue++ +}, 16) +``` + +Or `setTimeout` + +```js +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: + +```js +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](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](https://developer.mozilla.org/en-US/docs/Web/API/window/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: + +```js +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: + +```js +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: + +```js +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: + +```js +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](https://davidwalsh.name/javascript-debounce-function) 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: + +```js +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](https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent) 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: + +```js +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: + +```js +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](https://codesandbox.io/s/3qw6q7j535) + +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](https://github.com/nkoehring/FreddyvsJSON/raw/master/blogpost/drawing.jpg) + + +### 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: + +```js +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`: + +```js +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](https://codesandbox.io/s/2w10vo897n) + +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: + +```js +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](https://codesandbox.io/s/nr8r6myz60) + +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: + +```js +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](https://codesandbox.io/s/v0l8v95nr5) + +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: + +```js +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](https://codesandbox.io/s/x765pl1zm4) + +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: + +```js +this.shipSpeed = 5 // pixel per frame +``` + +And use it as a multiplicator: + +```js + 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: + +```js + 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](https://codesandbox.io/s/kxpn09n077). + +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. + +```js +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: + +```js + 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](https://codesandbox.io/s/j4rzoq5kqy) + +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](https://nkoehring.github.io/FreddyvsJSON) adds some more elements but uses only techniques described in this article. Feel free to check out [its source code](https://github.com/nkoehring/FreddyvsJSON) 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/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md b/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md new file mode 100644 index 0000000..b0efa21 --- /dev/null +++ b/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.md @@ -0,0 +1,244 @@ +# 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](https://dev.to/koehr/a-store-implementation-from-scratch-using-vue3-s-composition-api-3p16). Feel free to join the discussion there. + +--- + + +At some point I started moving a side project over to [Vue3](https://github.com/vuejs/vue-next) (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](https://vuex.vuejs.org) 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](https://github.com/vuejs/vuex/tree/4.0). 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: + +```html +
+
{{ hello }}
+ + +
Clicked {{ clicks }} times
+ +
+``` + +This is how an Options API example would look like: + +```js +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()`: + +```js +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 why`name.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](https://composition-api.vuejs.org/api.html) is the place to go! There are also great courses on [VueMastery](https://vuemastery.com). + +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: + + +```js +// 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](https://codesandbox.io/s/vue3-playground-lf16m?file=/src/index.js) 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: + +```js +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): + +```js +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: + +```js +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: + +```js +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: + +```js +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: + +```js +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/blog/index.md b/blog/index.md index d5513e5..99734f3 100644 --- a/blog/index.md +++ b/blog/index.md @@ -1,27 +1,83 @@ -*Sometime, 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.* Last updated: 2024-05-13
- +
- Example Title - (3min) + 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. +

- +
- Example Title - (3min) + 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 new file mode 100755 index 0000000..cffc730 --- /dev/null +++ b/build.sh @@ -0,0 +1,3 @@ +deno run --allow-read --allow-write bin/til.ts && +deno run --allow-read --allow-write bin/blog.ts && +./bin/vss build 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 new file mode 100644 index 0000000..e1934ab --- /dev/null +++ b/dist/blog/2016-12-04-the-price-to-crack-your-password.html @@ -0,0 +1,383 @@ + + + + + + + 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:

+
    +
  • 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
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:

+ +
+
+ + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + diff --git a/dist/blog/2017-04-09-the-magic-0xc2.html b/dist/blog/2017-04-09-the-magic-0xc2.html new file mode 100644 index 0000000..10ecc59 --- /dev/null +++ b/dist/blog/2017-04-09-the-magic-0xc2.html @@ -0,0 +1,121 @@ + + + + + + + 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

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + diff --git a/dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html b/dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html new file mode 100644 index 0000000..0d2e951 --- /dev/null +++ b/dist/blog/2017-08-17-vuejs-reactivity-from-scratch.html @@ -0,0 +1,152 @@ + + + + + + + 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.

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + 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 new file mode 100644 index 0000000..df16f18 --- /dev/null +++ b/dist/blog/2019-01-10-running-write-freely-on-arm.html @@ -0,0 +1,195 @@ + + + + + + + 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!

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + 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 new file mode 100644 index 0000000..1e9c4c3 --- /dev/null +++ b/dist/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.html @@ -0,0 +1,107 @@ + + + + + + + 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.

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + diff --git a/dist/blog/2019-05-03-freddy-vs-json.html b/dist/blog/2019-05-03-freddy-vs-json.html new file mode 100644 index 0000000..624f857 --- /dev/null +++ b/dist/blog/2019-05-03-freddy-vs-json.html @@ -0,0 +1,672 @@ + + + + + + + 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 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.

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + 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 new file mode 100644 index 0000000..50b5db1 --- /dev/null +++ b/dist/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.html @@ -0,0 +1,275 @@ + + + + + + + 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?

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + diff --git a/dist/blog/index.html b/dist/blog/index.html index cbd7437..617e543 100644 --- a/dist/blog/index.html +++ b/dist/blog/index.html @@ -3,7 +3,7 @@ - + Weblog aka Blog // the codeartist — programmer and engineer based in Berlin @@ -36,28 +36,79 @@

    Weblog

    -

    Sometime, 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.

    Last updated: 2024-05-13

    - +
    - Example Title - (3min) + 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. +

    - +
    - Example Title - (3min) + 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 index b648c2f..23daf96 100644 --- a/dist/cv/index.html +++ b/dist/cv/index.html @@ -3,7 +3,7 @@ - + CV/Resume // the codeartist — programmer and engineer based in Berlin diff --git a/dist/index.html b/dist/index.html index 3042acb..aed241c 100644 --- a/dist/index.html +++ b/dist/index.html @@ -3,7 +3,7 @@ - + Norman Köhring // the codeartist — programmer and engineer based in Berlin diff --git a/dist/now/index.html b/dist/now/index.html index 1bb7d7a..12a59e6 100644 --- a/dist/now/index.html +++ b/dist/now/index.html @@ -3,7 +3,7 @@ - + /now // the codeartist — programmer and engineer based in Berlin diff --git a/dist/posts.css b/dist/posts.css index 4bfaf00..3f8849d 100644 --- a/dist/posts.css +++ b/dist/posts.css @@ -6,12 +6,16 @@ main.posts > #content > h1 { } main.posts article { - margin: 1rem 0; + margin: 2rem 0; } main.posts article>div { line-height: 2; } +main.posts article>p { + line-height: 1.4; +} main.posts article>time, -main.posts article>div>a.external { +main.posts article>div>a.external, +main.posts article>div>.reading-time { color: gray; } diff --git a/dist/projects/index.html b/dist/projects/index.html index 3b6c62d..326e406 100644 --- a/dist/projects/index.html +++ b/dist/projects/index.html @@ -3,7 +3,7 @@ - + Active Projects // the codeartist — programmer and engineer based in Berlin diff --git a/dist/setup/index.html b/dist/setup/index.html index 7773b60..274c679 100644 --- a/dist/setup/index.html +++ b/dist/setup/index.html @@ -3,7 +3,7 @@ - + My Setup // the codeartist — programmer and engineer based in Berlin diff --git a/dist/stack/index.html b/dist/stack/index.html index ac6ccc2..9953b50 100644 --- a/dist/stack/index.html +++ b/dist/stack/index.html @@ -3,7 +3,7 @@ - + My Stack // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2021-08-31.html b/dist/til/2021-08-31.html index 4e30ab6..9430058 100644 --- a/dist/til/2021-08-31.html +++ b/dist/til/2021-08-31.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2021-09-03.html b/dist/til/2021-09-03.html index 3b0554c..1b5cae5 100644 --- a/dist/til/2021-09-03.html +++ b/dist/til/2021-09-03.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2021-09-04.html b/dist/til/2021-09-04.html index 5897fc0..281810d 100644 --- a/dist/til/2021-09-04.html +++ b/dist/til/2021-09-04.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2021-09-05.html b/dist/til/2021-09-05.html index 5dd7044..f9e4967 100644 --- a/dist/til/2021-09-05.html +++ b/dist/til/2021-09-05.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2022-02-22.html b/dist/til/2022-02-22.html index f117f51..869ae55 100644 --- a/dist/til/2022-02-22.html +++ b/dist/til/2022-02-22.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2022-03-22.html b/dist/til/2022-03-22.html index 475506f..093e799 100644 --- a/dist/til/2022-03-22.html +++ b/dist/til/2022-03-22.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2022-03-28.html b/dist/til/2022-03-28.html index 8ab2ef1..a8602ac 100644 --- a/dist/til/2022-03-28.html +++ b/dist/til/2022-03-28.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2022-04-25.html b/dist/til/2022-04-25.html index 89b59ee..cdc6d0d 100644 --- a/dist/til/2022-04-25.html +++ b/dist/til/2022-04-25.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2022-06-15.html b/dist/til/2022-06-15.html index 2776c82..6ab7b17 100644 --- a/dist/til/2022-06-15.html +++ b/dist/til/2022-06-15.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2024-05-12.html b/dist/til/2024-05-12.html index a5a6c02..aa20a57 100644 --- a/dist/til/2024-05-12.html +++ b/dist/til/2024-05-12.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin diff --git a/dist/til/2024-05-13.html b/dist/til/2024-05-13.html new file mode 100644 index 0000000..405910e --- /dev/null +++ b/dist/til/2024-05-13.html @@ -0,0 +1,83 @@ + + + + + + + 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.

    +
    +
    + + +
  • home
    • +
  • /now
    • +
  • /til
    • +
  • /projects
    • +
  • /blog
    • +
  • /cv
    • +
  • /stack
    • +
  • /setup
    • +     + + + + diff --git a/dist/til/index.html b/dist/til/index.html index 9414718..2f469c3 100644 --- a/dist/til/index.html +++ b/dist/til/index.html @@ -3,7 +3,7 @@ - + Today I learned // the codeartist — programmer and engineer based in Berlin @@ -38,6 +38,13 @@

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

    Last updated: 2024-05-13

    +
    diff --git a/static/posts.css b/static/posts.css index 4bfaf00..3f8849d 100644 --- a/static/posts.css +++ b/static/posts.css @@ -6,12 +6,16 @@ main.posts > #content > h1 { } main.posts article { - margin: 1rem 0; + margin: 2rem 0; } main.posts article>div { line-height: 2; } +main.posts article>p { + line-height: 1.4; +} main.posts article>time, -main.posts article>div>a.external { +main.posts article>div>a.external, +main.posts article>div>.reading-time { color: gray; } diff --git a/til/2024-05-13.md b/til/2024-05-13.md new file mode 100644 index 0000000..b1ef36f --- /dev/null +++ b/til/2024-05-13.md @@ -0,0 +1,5 @@ +# 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 index 5a9e802..cd665df 100644 --- a/til/index.md +++ b/til/index.md @@ -2,6 +2,14 @@ Last updated: 2024-05-13 + +