Life pro tip:

Google Maps thinks restaurant reviews from years ago are the "most relevant" reviews.

Things change. Restaurants decline, get new owners, etc.

Sorting by Newest has proven much more informative for me.

Right now, LLMs are shaking up the way we live life and access information. There's a lot of debate around how useful they can be if they'll lie to you.

Everything lies to you

When I get info from an LLM, I affectionately tell folks "the hallucination box says..."

But this isn't unique to LLMs!

• Google searches are full of incorrect or inapplicable information. A core skill of web search is sorting out what's true and what's relevant.
• StackOverflow famously closes questions as duplicates, which are not actually duplicates. Accepted answers can be wrong, outdated, or solve a problem you don't have while confidently proclaiming it's you who's solving the wrong problem.
• People you know get things wrong all the time. Wrong facts, bad opinions, faulty memories.

Nobody argues these shouldn't be used because they get things wrong. We just know we have to use our judgement.

But those are powered by people. LLMs are machines. That changes our expectations.

Which seems strange, because personal computers are famous for behaving in faulty, erratic, inscrutable ways. Yet have hold them to the standard of their best days, when they function with unerring determinism.

I'm going to keep using LLMs for personal use. Rather than grump that they're unreliable, I'd rather build the skill of assessing when they're right or wrong, like I have for other tools. That way I get the benefits.

Programmatic use is harder, since there's no human in the loop to exercise judgement, and I'd like to use LLMs in exactly the situations that are hardest to algorithmically verify. But I'm sure I'll figure how to make them useful there, too.

How do you rate a board game? A movie? A restaurant? You want a scale with consistency and clear communication.

What do people normally do?

There are two main scales:

1. A, B, C, D, F
2. 1–5, 1–10, 1–100

These both have the same problem: ambiguity. Everyone has a different idea of which values map to good / bad / meh / average. Is a C "average", or is it falling short of expectations?

Rotten Tomatoes considers < 60 bad, 60–74 good, and 75+ really good.

Metacritic ranges are < 49 is bad, 50–74 is average or uncertain, 75+ is good. So there's a 10 point range (50–59) where Metacritic thinks something is alright, but Rotten Tomatoes doesn't.

Net Promoter Score uses 1–10, but their interpretation is unintuitive. 9–10 are beneficial customers, 7–8 do nothing for you, and ≤ 6 are harmful to your reputation. Before learning this, I figured rating a product an 8 was pretty good!

Amazon, Uber, etc. all use a 5-point scale. A 4.7 means steer clear of that product or driver! Or maybe it's 4.3? Well, definitely avoid anything under 4.

On Google Maps, a 4.7-star restaurant in one city might be a 3.2 in another.

No one can agree on what number even means good vs bad, much less how good or bad! Adding digits of precision only makes things worse: if you're not sure what somebody's 7 vs 8 means, having them give you a 72 sure won't help.

Introducing the "Three" Scale

I have converted all my friends to use this. They start off reluctant: it's weird, and what's wrong with 1 through 10? But they quickly stop grumbling when they see how easy it is to communicate our experiences to each other, and then make decisions from that.

How it works

Everything is rated from −3 to +3.

Zero is neutral: "I have no strong feelings one way on the other". Take it or leave it.

+1 is mild positive sentiment. It's alright, if there's nothing better available.

+2 is strong positive sentiment. You'll normally say 'yes' to eating here, watching this, playing this.

+3 is one of the best of its kind. Your favorite restaurants, and the movies you tell everyone they have to see. It just doesn't get better than this!

Negative numbers are the same, but for hating something.

"Okay but so what?"

Now, you & your friends have a common language for ratings. Now, they're legible.

You agree what's neutral. You agree what's positive, and what's negative. No guessing. There's not much room for ambiguity in between 1 and 3.

If someone in your group gives the restaurant a −1 rating, it's clear that place shouldn't be in the group's normal rotation. If they said −2, you had better have a good reason for going back. If they'd said "C-"... who knows what that means 🤷‍♂️

My wife and I watch the trailers in the movie theater and whisper our ratings. In one word, we each know whether we're going to see a film together, separately, or at all. Whether we'll spend to see it in theaters, or wait for streaming.

I keep a spreadsheet tracking the ratings my board gaming group gives games. Because everyone's speaking the same language, I can sort & group games to see what old favorites we should replay.

The lack of precision helps, not hurts. If this was widened to ±10, we could at least tell positive/neutral/negative, but we'd be back to guessing how a +5 is different from a +7.

I don't think I've found a situation where the Three Scale is worse than letter grades or 1–10.

Some friends and I pondered if it should be cut down to ±2 or ±1, but it's not clear that there's a big win there. ±3 seems like the right granularity to express mild/strong/excessive sentiment.

"I don't want to explain this to people!"

In my experience, you just have to say "I rate things from −3 to +3". That's it — they get it.

In conclusion

It's great! Use it!

Appendix: where did this come from?

I swear I read about this in some medical or social sciences research paper. I recall researchers asked subjects to rate something on the Three Scale, and I loved the idea. But any time I mention this, nobody's ever seen it before. Even people who read social science research.

I charge my EV at home, but for ✨reasons✨ I use a level 1 charger that's outdoors and exposed to the elements. There are quite a few waterproof chargers, all of which require a plug adapter that's not waterproof.

(Not that any of the product listings spell that out, so I'll bet someone's burned their house down thinking the entire product was waterproof.)

Anyways, I spent quite a while figuring out how to waterproof the plug adapter. It's far, far too large for outdoor plug covers. It's too large for many utility boxes. The cords are thicker than most waterproof housings accommodate, and they don't bend enough to be routed out some housings' portholes.

It turns out there's an easy answer: silicone tape, found at your local hardware store. It's waterproof, UV resistant, electrically insulating, and withstands extreme heat & cold.

Just wrap it around your plug, stretching it out as you go. There's no adhesive - the material molecularly fuses to itself, leaving no gaps or leaks.

Works great, and doesn't require installing some kind of housing, and fits anything.

My brother & his partner are up near Asheville, caught in the aftereffects of hurricane Helene. Most pressing for them is that Helene destroyed most of the city's water infrastructure, and it'll be weeks before even non-potable water starts flowing in most parts of the city.

They have access to an in-ground well with a limited water supply, but it's not near anything. So they're trucking water around in drums, siphoning it into buckets with a hose.

I brought them a used IBC tote I got off Facebook Marketplace, which are cheap and abundant in my area. 330 gallons of potable, food-grade water storage. I also brought a Drummond shallow-well water pump from my local Harbor Freight.

It took us five days of work to connect it to his home plumbing, because neither of us are plumbers, and the pump's installation instructions lied to us.

Here's the stuff we struggle-bussed our way through, so you don't have to.

(A) Put the check valve (only) on the intake side

The pump's installation instructions showed a check valve (one-way water flow) installed in between the pump and the house

This is wrong! It will prevent the pump from knowing the downstream pressure, so it'll short-cycle (rapidly turn on and off).

You do need a check valve installed on the water intake line. Yes, even if you already have a foot valve! When the pump shuts off, the intake line depressurizes. That pulls water backwards through the pump, depressurizing the outlet, and the pump short-cycles trying futilely to repressurize the outlet line.

(B) The pump must be horizontal

The pump must be installed horizontally, not vertically. The instructions are ambiguous about this, only saying it must be "level". But yeah, horizontal.

(C) Keep the pump uphill of the water source

We didn't confirm this still mattered after we figured everything else out, but it's mentioned in the instructions, so give it some thought.

We initially had the pump in the basement, with the water intake hose running downhill from where the IBC tote was installed. This did not make the pump happy, possibly because the weight of the water in the line added unexpected water pressure to the pump.

Once we moved the pump above the IBC tote's elevation, things got better.

(D) Check your home's water pressure tank

We found out ours was blown, so the pump couldn't maintain pressure. We bought a new one, correctly sized for the home (the old one was was not), and set its empty pressure to 28psi (2psi below the pump's 30psi cut-on pressure).

This was critical, as it gave the home a place to store pressurized water, and thus gave the pump something to pressurize.

We thought the pump would just hold the water lines at pressure, but that never worked for us. Worth calling out: we tested shutting the valve between the pump and the house to isolate variables, but this was never going to work, because the isolated portion of the system didn't include a pressure tank. More short-cycling ensued.

If you bought the pump model with the built-in accumulator tank, this might not be an issue. But that's just a guess.

(E) Open your faucets

You'll get air in the system and the pump will struggle to reach & maintain pressure if you don't get that air out. Go run your faucets while the pump runs.

(F) Get the right size outlet hose

This particular pump takes a 1¼" outlet hose. The instructions don't mention the size. The plastic plug is labeled 1.2", but that's yet another lie. It's 1¼".

(G) Verify how far the water is being drawn

The pump can only pull water so far. It seems to be more forgiving of flat terrain than of pulling the water uphill, but still, keep the IBC tote and the pump near each other if you can.

(H) Keep that pump primed

When you keep disconnecting & reconnecting your hoses you can lose prime on the pump as it leaks water out. Re-prime it as appropriate.

(I) Use a non-compression hose

If you're using hoses for your water intake/outlet, be sure they're non-compression hoses. The pump will put a lot of suction and expansion pressure on the water lines, and an ordinary garden hose will shrink or expand accordingly. When the pump shuts off that pressure will go away and the hose will return to its normal size (changing its volume in the process), which changes the pressure in the hose, and the pump kicks on again.

The pump's correct behavior

If everything is working right, you should see the pump running smoothly while it reaches pressure. You can confirm it's pressurizing by attaching a tire pressure gauge to your water pressure tank.

Once the pump reaches pressure (50psi), it will gracefully shut off entirely, until you run enough water that pressure falls below 30psi. The pressure gauge will not read "zero", which we interpreted as the pump kicking in a safety cut-off after too much short-cycling.

When correctly installed, the pump will not short cycle, stutter, or run continuously.

I've only ever used a single SIM in my phone at once because I live in a well-covered city, but I was recently on a trip to the Michigan U.P., which is… not well-covered.

My Android phone (a Pixel 8) supports eSIMs, which are just pretend SIMs you download from The Internet™. I've never used one before — the last time I switched phone service, physical SIMs were all the rage.

So that begs the question: if eSIMs are imaginary, how many can my phone have at once? I mean, there's no physical constraint, like the single SIM card tray in my phone. So, how many?

Google's support page says you can have two SIMs: two physical, two eSIM, or one of each. Well, you can't have two physical in a Pixel since they don't have two card slots, but if they did, then you could.

But what happens if I download more?

So I kept my existing phone plan, bought another to give me extra coverage on the trip, then spent $4 on a third phone plan just to see what would happen.

Survey says:

I can only have two SIMs active. If I add a third, my phone asks me to deactivate one of the active SIMs. I can switch back and forth between any pair of SIMs I please, and my phone service will stay active for all of them, but I can only use two at a time.

For completeness, of the two that are active, I can choose which is my preference for calls and for SMS. I can pick one to be "it" for mobile data. There's a toggle on the other SIM to "use this network when it has better availability", but based on my time in the U.P., I'm not sure it worked very well. My phone often had no connectivity, even when at least one network showed a bar.

How many total SIMs can the phone hold? I haven't seen any official answer, but over on Mastodon, Alvan thinks it's 1 SIM + 5 eSIMs for his Pixel 7.

This morning I went down to the Apple store at opening so I could do a demo. I was 50/50 on whether it'd be just me, or a line around the block. An hour ahead of opening there was one other guy there. At quarter-til, when they started taking names, 11 people.

The 20 Apple employees applauded and cheered as we entered the store. It was very surreal.

TL;DR lots of good, some underwhelming. More compelling than I expected. Some hurdles might go away after an adjustment period. Not sold at $3,500, but if they release a non-Pro for say $1,500 that'll be pretty tempting.

Physically, wearing it feels fine. I stopped even noticing I had it on after a minute or two. I tried both headbands, strongly preferred the single-loop one. Two-loop felt harder to adjust correctly, less secure, and less comfortable. Weight didn't bother me for the ~15 minute demo I got, hardly noticeable.

They stuck my glasses into a machine to measure the prescription, then selected from the ~100 sets of lenses they had on-hand. My prescription is mild, and I felt I could see clearly while using the device. A guy I met in line has a -8 prescription. Apple had lenses on hand that were either a match, or close enough. He had a good demo experience, but after the demo he found the transition back to his polycarbonate glasses jarring, since they have strong lensing effects.

After calibration (look at dots and click them) it dropped me straight into AR. It feels good, though imperfect. Significant motion blur if I turn my head while looking across the room. But holding still or moving slowly, I have no problem seeing everything around me. I don't feel isolated from my environment at all. Pass-through is noticeably dimmer than IRL. And foveated vision makes the scene seem less than completely clear in my peripheral vision. But I don't think I'd need to remove my device for anything unless I was simply done using it.

There was an Apple employee seated beside me running my demo. I found it easy to chat back and forth with him, and basically forgot we were separated by a screen and cameras (except when immersive mode was on, more on that below). It just felt like a normal conversation.

Graphics overlaid on top of pass-through are rock-steady. They stayed exactly in place, no matter how much I rocked or shook my head. Aesthetically, overlaid graphics integrated naturally into the scene. Felt like they were supposed to be there, like a natural part of my vision (as much as anything artificial can).

Positioning windows around me worked well, felt fine. I could place them in X/Y/Z space, and e.g. overlap behavior felt intuitive, even though they intersected at angles (in an arc centered on me). The device is smart about mixing windows into the environment. Initially a window was blocking my view of the guy running my demo. I moved it to the background and device started drawing the window behind the guy. I could also move windows forward to do the equivalent of sitting closer to the screen.

Pinch controls worked alright, a little finicky. For the first minute or so, I was naturally resting my off-hand in my lap in a pose that the Vision Pro mistook for pinching, but I quickly adjusted to stop accidentally clicking everything I saw. Pinch to click, pinch+drag to scroll, pinch both hands and pull/push apart to zoom. A few times the pinch didn't catch, unclear if it's because I need practice, because I pinched too soon, or if it's a technology thing.

The devices has two buttons: one for photo/video (did not use), and a crown that you spin to control immersiveness, and press as the back button, or to pull up the app list if everything is closed.

The whole focus-follows-eyes felt natural for me. But I went in ready, having seen reviews that people were accidentally looking away from whatever they wanted to click. But it was awkward, as there's a noticeable pause between when I saw something and when it became clickable. Unsure if this is a design choice or not (i.e., to keep the display from going nuts with focus events as you look around). Made it feel slow to interact with things, and I kept trying to click before it was ready. I'd probably get used to the timing in a day or so of use. I did learn that my eye flits around more than I realized.

The device tries to be smart about auto showing+hiding buttons and window controls, but I found it confusing. The handle to reposition windows, close things, change volume, whatever, was often not present when I wanted it and I was never sure what I was supposed to do to see it. Felt like sometimes it would appear if I stared where it was supposed to be, sometimes required a click, etc. But if I clicked, sometimes that did something else. Could just be a learning curve. Not enough time with the device to tell if its behavior was consistent in all situations, or if it was truly doing different things at different times.

They walked me through reading a web page, black text on white background with some images. It was rendered crisply, no pixelation. For (outdated) perspective, on my Oculus Rift I can barely read system menus. On the Vision Pro, I'm not sure I could see pixels at all. Foveation aside, I had no trouble reading anything, and I'll bet if I spent much time in an immersive scene I could nearly forget I wasn't physically there.

Yet it felt challenging to read the web page. The foveated rendering left me unable to pull information from my periphery, and I didn't realize how much I relied on that. I could only "see" things my eyes were pointed directly at. That made it hard to skim, or keep track of where I was on the page. I kinda feel like I had to read slowly and deliberately. As someone becomes proficient at reading, they stop reading letters and start skimming word shapes. The experience made me feel like I rely on skimming sentence shapes, too, and I couldn't do that - I could only really see the word I was looking at. Maybe I'd get used to this, I don't know. The actual field of vision was fine (how far around me the scene wraps); no worse than a motorcycle helmet, maybe better. First impression is I'd clearly rather do a workday with a laptop than with a Vision Pro, mostly because of foveation while reading text.

And again, the foveation was noticeable when looking around the room I was in. Everything else felt effortless to look at, and looked great. Apps, photos, videos, system UI.

This is what things looked like. From Tobii.

They had some 3D recordings, one from an iPhone and I think another from a Vision Pro, and some stuff that resembled National Geographic footage. The NatGeo-style stuff was 180° wrap-around, the rest was a flat plane like a normal phone video, only... 3D-ified. I felt I was present in the scenes in a way that's truly hard to describe. Closest thing is when I played the Oculus game Lone Echo, free-floating around a space station. Like I wasn't watching a video, I was filming the video, in-person. I can see this being very compelling for personal moments, and if the tech ever becomes widespread, I'd easily see it replacing 2D feature films (even without wrap-around view).

One scene, sitting on a lake shore during the rain, I cranked up to full-immersive and it felt incredibly peaceful. I would have just sat there in that scene relaxing for as long as I could, if they'd let me. Very therapeudic. Reminds me of when I had solitude at sunset at White Sands.

Immersive mode works great. Shut out everything around me, made the display my whole world. Passing through people's faces did not work well. I could barely see the guy running the demo, like some ghostly phantasm in the shadows. I tried turning down the immersive knob, but it just started letting in background details without making the guy beside me any clearer, until I was basically back to pass-through.

The knob for pass-through vs immersive has a lot of positions between the two, but I didn't see any point to the in-between. It felt like all knob positions were basically-pass-through or basically-immersive. I didn't feel enough of a gradual change to matter.

They didn't put the dinosaur app in the demo script. The guy I met ignored the script and went and found it, said it totally blew him away.

They did not have me do any photo/video capture.

Sound is very good, to the extent I could evaluate in that environment. It doesn't do noise-canceling, but it felt that way because when stuff played it felt like the Apple store's sounds disappeared. Partially the volume was set a bit high, but even after turning it down, it still felt like the headset was all I was listening to.

The light visor kept falling off in my hands when I held the device. It's only attached with a weak magnet (magsafe-like), and it disconnected any time I held the headset there. I'd probably still disconnect the visor all the time, even once I got used to holding the device by the bezel.

There were one or two moments when I tugged the battery cable trying to look around at 360 scenes, Battery pack was on the seat beside me, but the cable wound up running down my back where it was pressed into the backrest, so it didn't move freely. Probably not a problem most of the time, but I don't think it's practical to deliberately position it somewhere safe.

They didn't set up anyone's Persona for demos, so I couldn't see what the fake-eyeballs thing looked like from the outside.

I didn't try out typing, but I sure wouldn't like to do much of it with the pinch gestures. If I connected a keyboard it'd be fine.

I don't see this replacing a laptop, at least not until the foveating stuff is better. Even then, maybe not. It's supplemental. But it could easily become most of my leisure computing. I'd almost certainly prefer watching movies this way rather than using my laptop, TV, or a theater (if I'm not watching socially). And it would be incredible if scenes were filmed in that immersive mode, where it felt like I was really there. I've watched 3D movies and it's just not the same.

Seeing other people using the Vision did not give me a weird dystopian creepy feeling. Of course, they were all very animated, talking with their demo handlers and being excited to try new things. Might be different if they go all dead-eyed zombie WALL·E passenger. But there's a glimmer of hope that it won't be stigmatized like Google Glass was. Doesn't look dorky enough to be a problem either, but I'm a lot less sensitive to that aesthetic than others, so take that with a grain of salt.

ReadStuffLater uses emojis to tag content †. It's simple, it's fun, and it affords basic content organization without encouraging users to spiral into reinvent-Dewey-Decimal territory.

There's just one problem: data validation. When the client tells my server to tag a record, how can the server confirm the tag is actually an emoji? I mean, I shouldn't accept and store just anything in that field, right?

This is a much gnarlier problem than it has any right to be. If you want the TL;DR, see what I did and what I wish I'd done, and an improved regex solution!

Failed idea #1: Use Regex character classes

My first thought was to google around for this, and everyone recommends regex! Everyone! Well that seemed easy.

There is a recent(?) extension to regex that lets you specifically ask, "is this an emoji?"

Except it's wrong. And also not available everywhere.

const regex = /^\p{Emoji}$/gu;
console.log("🙂".match(regex))
console.log("*️⃣".match(regex));
console.log("👨🏾".match(regex));

> Array ["🙂"]
> null
> null

I mean, it produces kinda-okay results if you ask "does this string contain any number of emojis". But it fails hard when you ask "Is this string made of exactly one emoji, and nothing else?".

Also, it seems Postgres regex doesn't support these special character classes, so validation would be strictly at the application layer.

EDIT: Someone showed how to patch some of the holes in this approach and make it work. Check it out below!

Why does the regex give the wrong answer?

I'm glad you asked! It turns out there isn't really such a thing as "an emoji". You have code points, and code point modifiers, and code point combinations.

A great primer on this is Bear Plus Snowflake Equals Polar Bear.

Here's the dealio: Let's say we want to display the emoji for a brown man, "👨🏾". There isn't a code point for that. Instead we use "👨 ZWJ 🏿".

ZWJ is "zero-width joiner". It's a Unicode byte that gets used in I guess the Indian Devanagari writing system? But it's also a fundamental building block for emojis.

Its job is "when a mommy code point loves a daddy code point very much, they come together and make a whole new glyph".

Basically any emoji that includes at least 1 person who isn't a boring yellow person doing nothing is several characters stapled together with ZWJ. Some other things work this way too.

Some examples include: 👪 (man + woman + boy), 👩‍✈️ (woman + airplane), and ❤️‍🔥 (heart + fire).

(And flags are multiple code points that aren't connected by ZWJ! ††)

(If your computer doesn't have current or exhaustive emoji fonts (thanks, Linux!), you might see what's supposed to be a single glyph instead displayed as several emojis side by side, like how my computer shows "Women With Bunny Ears Partying, Type-1-2" as " 👯 🏻 ♀️".)

So our regex can't just check if a string is an emoji: many things we want to identify are several emojis stapled together.

(The way you want to think about your goal here is "graphemes" and "glyphs", not "characters".)

Fortunately, when I experimented, it looked like you have to join characters in a specific order, so when you add both skin tone and hair color ("👱🏿‍♂️") you can count on it happening in exactly one canonical byte sequence. Otherwise, we'd have to dive into Unicode normalization (a good topic to understand anyway!).

Edit: Someone showed me how to make this work. Check it out below!

Failed idea #2: Use Regex character ranges

Alright, so we can't just use the special regex "match me some emoji" feature. What about a regex full of Unicode character ranges? StackOverflow sure loves those!

Well, they're all either too broad or too narrow.

You get stuff like "just capture anything that's a 'Unicode other symbol'" (/\p{So}+/gu). This fails for the same reasons as approach #1, and also for the bonus reason that this character class includes symbols that aren't emojis ('❤').

Ah, but some other StackOverflow answer says to just use a regex for Unicode code points! That also fails the same way as approach #1, plus, nobody includes exhaustive code point ranges in their SO answers.

Here's a partial list of valid emoji:

Two things to note:

1. There are quite a few code ranges that include emoji! Not just handful that all the StackOverflow answers include. If you want zero false positives, you need (eyeballing it) a hundred code point ranges.
2. See all those grey empty spaces? That's non-emoji characters that are in those same code point ranges. You probably don't want to accept "ª", "«", etc. as emoji.

So you're either including a bajillion micro-ranges, or a handful of very wide ranges that will give false positives, or you're rejecting valid emoji.

And once you pick some ranges, I have no idea whether they'll include the new emoji the standard adds each year.

So validating code point ranges is a terrible approach. It's just plain wrong: emojis aren't individual code points in the first place, and you'll get a huge number of either false positives and false negatives.

Oh, don't forget that JavaScript uses UTF-16, while everything else in the world uses UTF-8. If you're building a regex with Unicode code points, all your hardcoded numbers will be different.

Failed idea #3: just stuff all possible emojis into a regex

Alright, so what if I just get a list of EVERY POSSIBLE EMOJI, and build a regex out of them like /🙂|😢|😆/. It's exhaustive, it's accurate, and it'll match individual, whole glyphs.

Except... *️⃣ broke my regex, because it's not its own symbol: it's a regular asterisk followed followed by other stuff: "* + VS16 + COMBINING ENCLOSING KEYCAP".

VS16 is the Unicode byte that says "Hey, this character can either look like text or like an emoji, please show it as emoji".

Regex wasn't happy about that - all it saw was a random asterisk in my pattern and it threw a fit.

I mean, even the markdown engine for this blog post mistook that as "please make the rest of my post italic" until I put the emoji into a code block.

But maybe I was on the right track trying to exhaustively match all emoji?

What worked for me

What I finally came up with was exhaustively validating emoji shortcodes instead of emojis themselves. Shortcodes are those things you type into Github or Slack to summon the emoji popup - e.g., ":winking_face:".

The great part about shortcodes is they're strictly simple characters. Off the cuff, I think it's all a-z and _. Unsure about numbers.

That makes them super convenient to store or pattern match on. Not so convenient for other reasons (see the next section).

So when a user picks out an emoji, I find its shortcode and store that in the database. When I display an emoji, I convert the other way.

To build my allowlist, I found an NPM package that holds the same data as the emoji picker I'm using. I wrote a script to extract all the shortcodes, generate all the appropriate variants, and turned that into a SQL list of values I could copy/paste.

I stuffed that into a database table and foreign key'd my records to it. (I previously used a CHECK constraint using IN, but that made schemas very noisy.)

I wrote the output of that file to disk and checked it into source control. Now every time I build the app I generate the data again and compare against the oracle, so if the package's list of valid emoji gets updated, I'll get a build failure until I update my allowlist.

Problem: solved ✅

What I wish I'd done instead

I should have done basically the same thing, except with the actual emoji. I used shortcodes because I got caught up in path dependence with the regex stuff. But if I'm already using a data structure of discrete strings, why not just use the emoji themselves?

There's a modest advantage in network / storage efficiency (why store lot bytes when few bytes do trick?), but the real advantage would be simplicity.

In the emoji dataset I have, an emoji like ":people_holding_hands:" 🧑‍🤝‍🧑 doesn't have different shortcodes for skin tone or hair color. It's just ":people_holding_hands:". Checking Emojipedia, I get the uncertain impression that shortcodes might not be standardized, and I see some tools have different shortcodes for skin tones, while others don't.

I had to make up my own encoding for that, including noticing the emoji might have zero skin tones (yellow figures), or multiple skin tones (two figures of different races).

I also have to do a lookup every time I display an emoji. In an ideal world, I'd lazy-load the emoji picker JS so it only downloads when the user actually wants to select an emoji.

But because I have to convert shortcodes to emoji, I have to load the picker Database on any page where I want to display an emoji, so I can figure out what glyph matches my stored data people_holding_hands:3:5.

If I were to revisit my implementation, I'd just store and validate straight-up emoji.

A more technical solution

Over on Lobsters, user singpolyma pointed out how to test a string without needing an oracle.

You use your language's tools to detect if the string is a single grapheme, and then you check if it either passes the Emoji regex character class, or contains the Emoji variant selector code point.

Here's what you do:

const isEmoji = (e: string) => {
  const segmenter = new Intl.Segmenter();
  const regex = /\p{Emoji_Presentation}/u;
  const variantSelector = String.fromCodePoint(0xfe0f);

  return Boolean(
    Array.from(segmenter.segment(e)).length === 1 &&
      (e.match(regex) || e.includes(variantSelector))
  );
};

On my test data set, 229 out of 3,664 emoji fail the regex test by itself, such as ☺️, ☹️, ☠️, 👁️‍🗨️. But all of those contain the VS16 Emoji variant selector byte!

This means you use the grapheme count to tell "does this look like one glyph to the user?", then follow up with "does this either show as an emoji by default, or get converted into one?". All the safety, no oracles!

Well... mostly. It does mean any byte sequence containing VS16 will be accepted, which isn't the same thing as a valid emoji...

Intl.Segmenter is available everywhere except Firefox. And Postgres cannot count graphemes or use the Emoji regex character class, so you can only do application-level data validation. But you're free from managing an allowlist, so there's that.

Footnotes:

⏎ Your emoji picker includes country flags, but the Unicode Consortium doesn't want to take sides on whether Taiwan is a real country.

So they dodged the issue: if your text includes a 2-letter country abbreviation encoded as emoji letters, it might or might not display as a flag, depending on how your device feels.

So you're free to include "🇹 🇼" in your text, and if you just so happen to be in a country that doesn't find Taiwanese sovereignty objectionable, you'll see it displayed as 🇹🇼. Otherwise you'll just see 🇹 🇼.

EDIT: New info from Lobsters: it looks like my information is outdated! Or maybe wrong! I mean the part about how flags are rendered is correct, but the "they don't say which flags are valid" part might not be.

At some point the list of acceptable country flags got enumerated. That file dates back to 2015, and references a Consortium task seeking to clarify what "subtags" are valid. That Atlassian task is newer than the Github commits, so I guess its timestamp is a lie, leaving me unable to tell how early the enumeration took place.

However, "depictions of images for flags may be subject to constraints by the administration of that region."

I would have learned this factoid sometime around the Unicode 6.0 release in 2010, so maybe they started enumerating country codes later, or maybe I just learned wrong in the first place.

⏎ Why emoji and not a normal tagging system with arbitrary text?

I want ReadStuffLater to be a very low-friction, low-cognitive-overhead experience. It's not a place to organize your second brain; it's just read-and-delete.

Simply making rich organization available can make people feel like they're supposed to use it. And once people think that's the kind of app this is, they'll start expecting features that are expressly out of scope.

Yet once a user saves hundreds of links, they need something besides one giant list. This is my attempt to split the difference. And for product positioning purposes, I want to signal "do not expect this to be the same as Instapaper".

If a more second-brain-flavored reading list is what you need, I recommend Instapaper, Pocket, or Wallabag. They're a take on this problem with a stronger focus on long-term knowledge retention.

My app ReadStuffLater fundamentally revolves around scraping web pages with the Microlink API. Sometimes that goes wrong: the target web page has a problem. Or Microlink does. Or the target throws up a captcha or blocks data center IPs or something.

I thought I'd done an alright job of handling all the cases that could go wrong. API errors are retried, website errors retry or do something sensible based on common status codes.

Yet I still get links that intermittently fail to scrape for no apparent reason. There are a couple usual suspects where I thought I'd handled all the failure modes, but they keep going wrong. And random pages have problems sometimes, too.

My strategy has been "notice failed scrapes, watch the logs while reexecuting the scrape, then fix whatever I see". This has problems:

1. Detecting a legitimate failure in hard. Sometimes a scrape unrecoverably fails for reasons outside my control. False negatives are real.
2. This doesn't let me diagnose transient failures, where everything is working again by the time I manually verify the problem.
3. It's a pain since I don't have good tools to peek into the scrape process. I'm always setting up something ad-hoc like console.log in local dev.

I think the right call here is an audit log. Every scrape would get its raw result stored in the DB. Status codes, body, Microlink metadata. Everything.

I guess I'd need a way to look up the audit records for a given link. A CLI script on the prod box would probably be okay. Maybe reformat the data in a way that's convenient to munge with jq.

The interesting question is: at what point should I have recognized that I needed an audit log?

Should I be logging ALL external API calls? What internal operations should I log? Do I just wait until I have problems and then start logging? I'm not sure.

The logical extreme of this is "just adopt event sourcing". And yes, that would solve this problem. But what other problems would it cause? Maybe I should just adopt it piecemeal, and not for the whole system? But then I'm paying the implementation complexity cost for minimal benefit.

Idunno. All I know is right now I sure need an audit log for this one piece of the system 🙂

I was recently on my way out the door when I knocked over a glass of water, spilling it across my Framework laptop. I panicked and tried to dab it up, but saw that water had seeped under the keyboard and was leaking out the bottom of the laptop. The screen began to flicker.

I held down the power button and began disassembling the laptop. In minutes I had the laptop in pieces and ran a hair dryer over it. Water had gotten into many nooks and crannies; every time I tilted the unit a new direction water ran out from somewhere I had missed.

I dried up all the water I could spot, and left the unit open to air out for about 24 hours.

The next morning I put it back together and it works fine!

I don't think I'd have been so lucky with other laptops I've owned. They've all been difficult to open, or purposely designed to keep users out. I'd have been at the mercy of however well they drain, with little assurance of when (or if) it was safe to power them on again.

My Framework was trivial to open, even while stressed and anxious, and I had the comfort of knowing that if it did break, I'd probably only have to replace the mainboard, and not the whole laptop.

My app includes content areas that expand and collapse. A lot like accordions, except they take up the whole page and can be huge.

When you open one, whatever's open gets closed, and that makes whatever you just clicked on jump around as the previous content area stops taking up space on the page.

Here's a code snippet I put together that keeps whatever you just clicked at the same spot in the viewport after the layout shift:

/**
 * This ensures that the element is at the same position within the viewport
 * after a layout shift.
 *
 * MUST be called BEFORE triggering the layout shift.
 *
 * IT can only do so much - if the layout shift cuts off enough content, the
 * element will still wind up positioned higher in the viewport than before.
 */
export const retainScrollPosition = (el: Element) => {
  const targetViewportPosition = el.getBoundingClientRect().top;

  requestAnimationFrame(() => {
    const newPagePositon = el.getBoundingClientRect().top + window.scrollY;
    window.scrollTo({ top: newPagePositon - targetViewportPosition });
  });
};

We have to pick a new health insurance plan this month, and we've had a tough time making the decision.

You can't just add up what you'll spend - what each thing costs depends on how much you've already spent!

And some things are inherently probabilistic - will I go through procedure X this year? How many visits will I need for situation Y? How many urgent care visits?

So complex and uncertain!

Inspired by vaguely recalling that I read Lucas F. Costa's blog post some time ago, I applied the Monte Carlo method to my health insurance decision.

I have a simplistic understanding of Monte Carlo simulations:

1. Assign probabilities to everything that can happen in your scenario
2. Randomly selecting outcomes for each possible event, then repeat the calculations a gazillion times
3. Measure how things typically play out

It can get much fancier (hello, MCMC!) but I think that's the gist of it.

I put together a simple TypeScript file with some arithmetic operations and calls to Math.random() and ran it with Bun. I punched in all the reasons my wife and I will or might spend on healthcare, added in the premiums, and took the average result.

Surprisingly, the expensive plan will save us a a small bundle this year, even accounting for the higher premiums.

I feel better about the decision since I did something resembling rigorous calculation of which plan is best. In past years, I've done my best to make a costs estimate, but I never feel confident in it.

Dokku has a Let's Encrypt plugin which works behind Cloudflare. There's just a little bit of chicken-and-egg setup involved.

Let's Encrypt needs to connect back to your server to validate ownership of your domain. You can't have Cloudflare's "full" TLS mode enabled when you're doing first-time validation, because in "full" mode Cloudflare will error out, failing to establish a TLS connection to your not-yet-TLS backend server.

You could disable "full (strict)" TLS mode in Cloudflare, but then you'll take all your sites down: Dokku does HTTP -> HTTPS redirects on all sites configured with TLS, and will thus reject the non-TLS inbound connections from Cloudflare's networks. Or more accurately, it'll receive an inbound HTTP request from Cloudflare's servers, return a redirect to HTTPS, which Cloudflare will pass on to the client, but the client is already at an HTTPS URL, so the client will enter an infinite redirect loop.

You can get around all this during first-time setup by disabling Cloudflare's proxying behavior on your domain while you get Let's Encrypt set up on Dokku. After it's set up, you can turn Cloudflare proxying on, and cert renewals should work fine, since Let's Encrypt validation checks routed through Cloudflare can still establish end-to-end TLS while your certs remain valid.

While at work I was upgrading graphql-code-generator, and found that the generated code no longer exports the type for a query node. Instead, the type of the whole query response was exported. But I had code that relied on having the node type available.

To solve this, I created a new type by reading attributes from deep in the response type.

interface Foo {
    bar: {
        baz: {
            zap: {
                zoop: number;
            }[];
        };
    };
}

type zoop = Foo['bar']['baz']['zap'][number]['zoop'];

If some of your properties are optional, you can use Required<T>. If they're possibly undefined, use Exclude<T, undefined>.

Recently, while building a simple Reddit clone, I wanted to lazy-load images and comments. That is, rather that loading all of the images and comments the instant I added a component to the DOM, I wanted to wait until the component was actually visible. This spreads out the impact of loading a page, both for the client and the server.

To do this, I used the IntersectionObserver API to create a higher-order Svelte component:

VisibilityGuard.svelte:

<script>
  import { onMount } from "svelte";

  let el = null;

  let visible = false;
  let hasBeenVisible = false;

  onMount(() => {
    const observer = new IntersectionObserver(entries => {
      console.log("entry", entries[0]);
      visible = entries[0].isIntersecting;
      hasBeenVisible = hasBeenVisible || visible;
    });
    observer.observe(el);

    return () => observer.unobserve(el);
  });
</script>

<div bind:this={el}>
  <slot {visible} {hasBeenVisible} />
</div>

This renders a div and stores the rendered HTML element in the el variable. Once the component has been rendered (onMount), we use IntersectionObserver to watch the component, calling a callback whenever the element intersects with our viewport. We track whether the element is currently visible, and whether it has ever been visible, and we pass those to our child component (slot).

So how do we use this component?

App.html:

<script>
	import VisibilityGuard from './VisibilityGuard.svelte';
	
	const images = new Array(100).fill(null).map((n, i) => [
		Math.floor(Math.random() * 500),
		Math.floor(Math.random() * 750)
	]);
</script>

{#each images as [x, y]}
	<VisibilityGuard let:hasBeenVisible>
		<div style="border: 1px solid black; min-height: 40px; min-width: 40px; padding: 5px; border-radius: 5px; margin-bottom: 5px;">
			<header>I am {hasBeenVisible ? 'visible' : 'invisible'}</header>
			<img src={hasBeenVisible ? `https://placekitten.com/${x}/${y}` : null} alt="a kitten" />
		</div>
	</VisibilityGuard>
{/each}

We import the VisibilityGuard component and use it to wrap our image. The let:hasBeenVisible directive declares a new variable that comes from our higher-order component, and we use that to determine whether to display our image (by setting or not setting a src attribute).

And that's that! Here's a REPL of this in action.

I needed to create a bottom nav (like what's used in many mobile apps) in CSS. Here's how I did it.

(CodePen)

<div class="container">
  <div class="content">
    <p>bar</p>
    <p>bar</p>
    <p>bar</p>
  </div>
  <nav>
    <p>foo</p>
    <p>foo</p>
    <p>foo</p>  
    <p>foo</p>
  </nav>
</div>

<style>
.container {
  height: 100vh;
  display: flex;
  flex-direction: column;
}

.content {
  flex: 1 1 auto;
  overflow: auto;
  align-self: stretch;
}
</style>

What are Sapper and Netlify CMS?

Sapper

Sapper is Svelte's answer to Next.js/Nuxt.js. It's a way of rendering Svelte code on the server so your site is compatible with JavaScript-free devices, and so it renders immediately instead of waiting for a JS blob to download, parse, and run.

Sapper ordinarily runs as a full server application, but using the sapper export command we can generate a static version of our site that we can host on Github Pages or, in this case, Netlify. That's a great way to have a very fast site that's free for small-to-medium traffic numbers.

Netlify CMS

Netlify CMS is as open-source content management system, meaning it's a way to create blog posts and web pages through a web page. Since it's from Netlify, the static site host, it's designed to work with static site generators like Hugo and Jekyll. We'll be adapting it to work with Sapper.

Putting these together

Adapting Netlify CMS to work with Sapper is pretty straightforward. First we'll follow Netlify's directions for adding the CMS to a generic site. That'll give us a web interface that drops Markdown files into our Sapper site's git repository. Next, we'll update our Sapper site code to see those Markdown files and render them as blog posts.

You can copy/paste the same code changes we make in this tutorial to support adding entire pages to Sapper, or to add multiple content sections, like a personal and a professional blog.

Let's get started!

* Note: If you want to skip all of this and just get something working, you can clone the repository I made for this tutorial.

Let's do it - Netlify CMS

Prepare your workspace

Create a project

Start your project by cloning the Sapper template git repository.

$ npx degit "sveltejs/sapper-template#webpack" my-site
$ cd my-site
$ npm install

Commit that project

Go ahead and commit and push this to Github so you can create your Netlify project, which is tied to your Git repo.

Create a new repository on Github, and substitute that URL in the fourth command.

$ git init
$ git add .
$ git commit -am "Degit'd the Sapper starter project"
$ git remote add origin <your github project URL here>
$ git push

Go to Netlify and create a project

Now that we have a barebones Sapper project in Git, it's time to tell Netlify that we'd like to host that project. Sign up at Netlify.com and begin creating your new Netlify project.

Click the button to create a new site from a Git repo.

Use Github as the source for your project. Netlify CMS only supports Github at this time.

Select the repo you created in Github

Configure your build process. Set the build command to generate the static Sapper site, and the publish directory to the directory where Sapper exports to.

Install the Netlify CMS

Back in our workspace it's time to add the Netlify CMS code to our project.

Add the CMS code

Create the directory static/admin, then add the below snippet to the file static/admin/index.html. This file contains the code that bootstraps the Netlify CMS.

<!doctype html>
<html>
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Content Manager</title>
</head>
<body>
  <!-- Include the script that builds the page and powers Netlify CMS -->
  <script src="https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js"></script>
</body>
</html>

Configure Netlify CMS

Edit static/admin/config.yml and add the following:

backend:
  name: git-gateway
  branch: master # Branch to update (optional; defaults to master)
publish_mode: editorial_workflow # Allows you to save drafts before publishing them
media_folder: static/uploads # Media files will be stored in the repo under static/blog-images/uploads
public_folder: /uploads # The src attribute for uploaded media will begin with /blog-images/uploads

collections:
  - name: "blog" # Used in routes, e.g., /admin/collections/blog
    label: "Blog" # Used in the UI
    folder: "static/_posts" # The path to the folder where the documents are stored
    create: true # Allow users to create new documents in this collection
    slug: "{{slug}}" # Filename template, e.g., title.md
    fields: # The fields for each document, usually in front matter
      - {label: "Layout", name: "layout", widget: "hidden", default: "blog"}
      - {label: "Title", name: "title", widget: "string"}
      - {label: "Publish Date", name: "date", widget: "datetime"}
      - {label: "Body", name: "body", widget: "markdown"}

Set up Netlify authentication

We'll use Netlify's authentication service -- called "Identity" -- tot let users log into our CMS and create posts. We'll also wire up Netlify with write access to our Git repo so the CMS can actually add the content to the repo.

Activate Identity

Follow Netlify's directions to activate Identity and connect your git account to your Netlify project. Also, invite yourself as a user to the project.

Add Identity code to your site

We need to add the Netlify Identity code to both our admin page (so we can log in) and our main site (so it can redirect us back to the admin after we log in).

Take this snippet: <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>

And add it to the head section of your static/admin/index.html:

<!doctype html>
<html>
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Content Manager</title>
</head>
<body>
  <!-- Include the script that builds the page and powers Netlify CMS -->
  <script src="https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js"></script>
+ <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
</body>
</html>

Also add it to the <svelte:head> section of your src/routes/index.svelte:

<svelte:head>
    <title>Sapper project template</title>
+   <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
</svelte:head>

3. You'll also need to add this snippet to the top of your src/routes/index.svelte:

<script>
  import { onMount } from 'svelte';

  onMount(() => {
    if (window.netlifyIdentity) {
      window.netlifyIdentity.on("init", user => {
        if (!user) {
          window.netlifyIdentity.on("login", () => {
            document.location.href = "/admin/";
          });
        }
      });
    }
  });
</script>

Success part 1!

Commit and push your code.

$ git add .
$ git commit -am "Configured the site to run the Netlify CMS"
$ git push

Wait for Netlify to deploy it, then visit your admin site (the URL will be your Netlify site + /admin, like https://awesome-bose-294ddb.netlify.com/admin), log in, and create a post! You won't see the post on your published site yet -- Sapper still doesn't know anything about the Netlify CMS content. Let's fix that!

Lets do it - Sapper rendering markdown blog posts

Here's where the real work comes in. Sapper, out of the box, reads posts from a rather unwieldy _posts.json file. We're going to replace that with reading from Markdown files that Netlify CMS creates in our repo.

Install dependencies

You'll need to install a few packages for managing the markdown files:

npm install mz glob markdown-it front-matter

• glob makes it easy to get a list of Markdown files
• mz wraps the standard Node.js fs library in promises, so we can async/await our way to success
• front-matter reads the metadata out of our blog posts and separates it from the markdown content
• markdown-it will render our markdown content

Update the blog.json server route

The built-in Sapper blog engine reads a list of all blog entries from the /blog.json server route, which is controlled by the src/routes/blog/index.json.js file. We're going to open that file and replace the whole thing with this:

import fm from 'front-matter';
import glob from 'glob';
import {fs} from 'mz';
import path from 'path';

export async function get(req, res) {
  // List the Markdown files and return their filenames
  const posts = await new Promise((resolve, reject) =>
      glob('static/_posts/*.md', (err, files) => {
      if (err) return reject(err);
      return resolve(files);
    }),
  );

  // Read the files and parse the metadata + content
  const postsFrontMatter = await Promise.all(
    posts.map(async post => {
      const content = (await fs.readFile(post)).toString();
      // Add the slug (based on the filename) to the metadata, so we can create links to this blog post
      return {...fm(content).attributes, slug: path.parse(post).name};
    }),
  );

  // Sort by reverse date, because it's a blog
  postsFrontMatter.sort((a, b) => (a.date < b.date ? 1 : -1));

  res.writeHead(200, {
    'Content-Type': 'application/json',
  });

  // Send the list of blog posts to our Svelte component
  res.end(JSON.stringify(postsFrontMatter));
}

Now, when the blog.json server route is called, Sapper will scan the list of markdown files at static/_posts/, read the metadata for each one, and create a list of the blog titles, dates, and any other fields (besides content) that we added to our Netlify CMS fields section.

Edit the per-post Svelte component

Next up, we need to update our Svelte component to fetch the Markdown files instead of the old JSON content, then render those files to HTML and present the content to the user.

Remove an unused server route

Sapper provides a server route for extracting post content from the _posts.js file. Since we're not using that file, we need neither the file nor the server route. remove both:

$ cd src/routes/blog
$ rm _posts.js [slug].json.js

Render markdown posts

Next, open src/routes/blog/[slug].svelte and replace both <script> blocks with this code:

<script context="module">                                                                                                                                                                                                                                                                   
  export async function preload({ params, query }) {
    // the `slug` parameter is available because
    // this file is called [slug].svelte
    const res = await this.fetch(`_posts/${params.slug}.md`);

    if (res.status === 200) {
      return { postMd: await res.text() };
    } else {
      this.error(res.status, data.message);
    }
  }
</script>

<script>
  import fm from 'front-matter';
  import MarkdownIt from 'markdown-it';

  export let postMd;

  const md = new MarkdownIt();

  $: frontMatter = fm(postMd);
  $: post = {
    ...frontMatter.attributes,
    html: md.render(frontMatter.body)
  };
</script>

We've changed the default Sapper code in two ways:

1. We fetch text from the server instead of JSON
2. We break up that text into metadata and content, and render the content.

When we put the metadata and content back together, we're passing the rest of the Svelte component the same data it expected to get from the old [slug].json.js server route, and now everything renders!

Success part 2!

See our work in action

Our site now works! You can see it for yourself by running npm run dev and visiting http://localhost:3000 .

Verify the exported site

If you want to verify your site exports correctly before committing and sending it to Netlify, you can do this:

$ npm run export
$ npx serve __sapper__/export

if the export command didn't produce any 500 messages, visit http://localhost:5000, click around and confirm that everything works like you expect.

Send it to Netlify

$ git add .
$ git commit -am "Configured the site to read and publish markdown blog posts"
$ git push

After waiting for Netlify to publish your site, you can visit your site and see the glorious blog post you created earlier!

You're now all set with a hosted and operational Sapper blog!

I've been working on a project that uses GraphQL via Hasura. Using Subscriptions (real-time updates to queries) is a key feature for my project, but it's one that most of the simpler GraphQL client libraries don't support. That leaves me looking at heavyweight tools Apollo. Apollo is pretty complicated to configure (I'm paying for a lot of features I don't use), and it _strongly_ steers you towards React hooks for accessing data; I had to dig pretty hard to find the documentation for their language-agnostic client library. I've really come to believe data fetches shouldn't be represented declaratively, at least not the way React hooks handles it. The ergonomics are poor and the flexibility is low every time I try it.

So I went looking for a GraphQL client that could handle GraphQL subscriptions, which was simple to set up and worked great when used imperatively.

[Edit: since originally writing this, I see urql is (now?) designed for more than just React use, and has docs for imperative, non-framework-specific usage (though that's clearly not what they're steering you towards). It looks simpler to set up, though I haven't tried it yet.]

The solution I settled on was to use the same underlying library that powers Apollo's subscriptions feature. It's simple to use from vanilla JS, and can be used for Query, Mutation and Subscription. The package is subscriptions-transport-ws.

Here's an example of making an authenticated GraphQL subscription request:

import gql from 'graphql-tag';
import {SubscriptionClient} from 'subscriptions-transport-ws';

const wsclient = new SubscriptionClient(
  'wss://example.com',
  {
      reconnect: true,
      connectionParams: {
        headers: {
          'Authorization': `Bearer <your token here>`,
        }
      },
    }
);

wsclient.request({
  query: gql`
    fragment transaction on transactions {
      id
      user_id
    }
    subscription SubscribeTransactions($user_id: String!) {
      transactions(where: { user_id: { _eq: $user_id } }) {
        ...transaction
      }
    }
  `,
  variables: { user_id: 'capncrunch' }
  // Don't forget to check for an `errors` property in the next() handler
}).subscribe({next: console.log, error: console.error})

Here is a minimal router for Svelte v3 using Page.js.

Whenever the route changes, Page.js sets a variable that holds the component that should be rendered for the route.

<script>
  import page from 'page';

  import Home from './views/Home.svelte';

  let route;
  let routeParams;

  function setRoute(r) {
    return function({ params }) {
      route = r;
      routeParams = params;
    };
  }

  page("/", setRoute(Home));
  page({ hashbang: true });
</script>

<svelte:component this={route} bind:params={routeParams} />