main
Norman Köhring 2 months ago
parent 9ac648c101
commit bc650f5bf1

@ -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 = `<article class="blog">
<time datetime="%DATE%">%DATE%</time>
<div>
<a href="/blog/%SLUG%.html">%TITLE%</a>
<span class="reading-time">(%READING_TIME_FAST% to %READING_TIME_SLOW% minutes)</span>
</div>
<p>
%ABSTRACT%
</p>
</article>
`
function getAbstract(lines: string[]): string {
const sep = '<!-- more -->'
const sep2 = '<!--more-->'
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))

@ -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).
<!-- more -->
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)

@ -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…
<!-- more -->
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)

@ -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.
<!-- more -->
<style>iframe{width:640px;max-width:100%;height:30em;}</style>
_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)
<iframe src="https://jsfiddle.net/ajwchnko/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/k72aoorc/1/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/2/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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.
<iframe src="https://jsfiddle.net/e2q9vme3/3/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/4/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/5/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/6/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/7/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/8/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/9/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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?
<iframe src="https://jsfiddle.net/e2q9vme3/10/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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?
<iframe src="https://jsfiddle.net/e2q9vme3/11/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/12/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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:
<iframe src="https://jsfiddle.net/e2q9vme3/14/embedded/?username=koehr" width="640" height="400" frameborder="0" sandbox="allow-modals allow-forms allow-scripts allow-same-origin allow-popups"></iframe>
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).

@ -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.
<!-- more -->
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!

@ -0,0 +1,36 @@
# Use OpenBSDs Spleen bitmap font in Linux
*Written 2019-01-10*
<span title="2019-01-09">Yesterday</span> 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).
<!--more-->
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 <span title="Glyph Bitmap Distribution Format">BDF</span> or <span title="thats a Macintosh thing">.dfont</span> but we need another strange format called <span title="Linux PC Screen Font Data with unicode directory">PSFU</span>. If we look at the description that comes with Spleen we only get tought how to make yet another strange format called <span title="Portable Compiled Format">PCF</span>. 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.

@ -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.
<!--more-->
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
<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](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.

@ -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.
<!-- more -->
---
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
<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:
```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?

@ -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
<article class="blog">
<time datetime="2024-05-12">2024-05-12</time>
<time datetime="2020-06-29">2020-06-29</time>
<div>
<a href="/blog/2024-05-12-example-title.html">Example Title</a>
(3min)
<a href="/blog/2020-06-29-a-store-implementation-for-vue3-composition-api.html">A store implementation from scratch using Vue3's Composition API</a>
<span class="reading-time">(6 to 8 minutes)</span>
</div>
<p>
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.
</p>
</article>
<article class="blog">
<time datetime="2024-05-12">2024-05-12</time>
<time datetime="2019-05-03">2019-05-03</time>
<div>
<a href="/blog/2024-05-12-example-title.html">Example Title</a>
(3min)
<a href="/blog/2019-05-03-freddy-vs-json.html">Freddy vs JSON: how to make a top-down shooter</a>
<span class="reading-time">(25 to 31 minutes)</span>
</div>
<p>
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.
</p>
</article>
<article class="blog">
<time datetime="2024-05-12">2024-05-12</time>
<time datetime="2019-01-10">2019-01-10</time>
<div>
<a href="/blog/2024-05-12-example-title.html">Example Title</a>
(3min)
<a href="/blog/2019-01-10-use-openbsds-spleen-bitmap-font-in-linux.html">Use OpenBSDs Spleen bitmap font in Linux</a>
<span class="reading-time">(2 to 2 minutes)</span>
</div>
<p>
<span title="2019-01-09">Yesterday</span> 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).
</p>
</article>
<article class="blog">
<time datetime="2019-01-10">2019-01-10</time>
<div>
<a href="/blog/2019-01-10-running-write-freely-on-arm.html">Running writefreely 0.7 on Arm</a>
<span class="reading-time">(4 to 5 minutes)</span>
</div>
<p>
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.
</p>
</article>
<article class="blog">
<time datetime="2017-08-17">2017-08-17</time>
<div>
<a href="/blog/2017-08-17-vuejs-reactivity-from-scratch.html">Vuejs Reactivity From Scratch</a>
<span class="reading-time">(8 to 9 minutes)</span>
</div>
<p>
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.
</p>
</article>
<article class="blog">
<time datetime="2017-04-09">2017-04-09</time>
<div>
<a href="/blog/2017-04-09-the-magic-0xc2.html">The Magic 0xC2</a>
<span class="reading-time">(3 to 4 minutes)</span>
</div>
<p>
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…
</p>
</article>
<article class="blog">
<time datetime="2016-12-04">2016-12-04</time>
<div>
<a href="/blog/2016-12-04-the-price-to-crack-your-password.html">The price to crack your password</a>
<span class="reading-time">(6 to 7 minutes)</span>
</div>
<p>
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).
</p>
</article>

@ -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