lhorie

Write better tests with one neat trick

TL:DR; assert your input

If you write non-trivial code, inevitably you'll run into a situation where setting up a test is not super readable. Maybe you have to mock a bunch of things, or the input data is a data structure that spans dozens of LOC, or maybe you are testing with a large-ish fixture that was defined in another file because linting or whatever.

Due to the nature of my job, I happen to read a lot of other people's code, so you can imagine how mildly annoying it is when I'm code reviewing something, and the test looks something like this:

test('codemod does what it needs to', async () => {

lhorie

// test.zig
const std = @import("std");

pub const io_mode = .evented;

pub fn main() void {
    parse("/somefile");
}

fn parse(file: []const u8) void {

lhorie

% yarn test   
yarn run v1.22.10
$ fusion test --configPath=./jest.config.js
Determining test suites to run...Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db

Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db

lhorie

Dear Javascript developer, OOP and FP are not opposites

In the Javascript community, I sometimes hear people say they prefer FP over OOP, and that FP is good and OOP is bad. The line of argument implies there's an FP vs OOP dichotomy, and that one should aim to use one and avoid the other.

I like to quote the Qc-Na parable because it illustrates a subtle but important insight about the two paradigms: they are not opposites and in fact have a lot in common. Here's the parable for those who haven't seen it:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, int

lhorie

Friday Fun: Svelte-like variable reactivity in 7LOC with with Proxy

Every once in a blue moon, I like to hack up some crazy toy proof of concept to get away from everyday's stiff serious production-ready coding. This morning, I decided to mess around with an idea of implementing something similar to Svelte's reactive variables, but using pure Javascript.

So here's that godawful eye-bleeding fun hack: a 7-line "svelte" (needless to say, it doesn't do nearly enough to be useful in the real world and breaks just about every best practice rule in the book because why the hell not)

https://codepen.io/lhorie/pen/BaRzgRe

Can you figure out why this works? Any ideas to make it more devilish/clever/insane are welcome :)

lhorie

var readtable = {
	"(": form,
	" ": space, "\t": space, "\n": space, "\r": space,
}
var white = " \t\n\r"
var atomEnd = " \t\n\r);"
var formEnd = ")"
var escape = "\\"
function parse(s) {
	s.marker = s.cursor

lhorie

flowchart LR

A[Hard] -->|Text| B(Round)
B --> C{Decision}
C -->|One| D[Result 1]
C -->|Two| E[Result 2]

lhorie

console.log(`%c ________________________________________
< mooooooooooooooooooooooooooooooooooooo >
 ----------------------------------------
        \\   ^__^
         \\  (oo)\\_______
            (__)\\       )\\/\\
                ||----w |
                ||     ||`, "font-family:monospace")

lhorie

So there were a few threads going around recently about a challenge to write the longest sequence of keywords in Javascript:

• https://twitter.com/bterlson/status/1093624668903268352
• https://news.ycombinator.com/item?id=19102367

There are, however, a few problems:

• These solutions use non-keyword tokens (null, true, false are actually Literals, not Keywords)
• One of the solutions isn't quite valid (new super)