FeoBlog & Deno

For a while I'd been maintaining 2 versions of the FeoBlog TypeScript client:

• The "main" one, in Node.js, used by the web UI.
• A port of that code to Deno.

But maintaining two codebases is not a great use of time. So now the Deno codebase is the canonical one, and I use DNT to translate that into a node module, which I then import into the FeoBlog UI, which you are probably using right now to read this post. :)

A Phone Number is a Liability

Is it weird that I'm starting to feel like having a phone number is not worth it?

First, I use actual phone conversations VERY rarely. If I'm home and want to have a voice conversation with someone, I usually use VoIP (usually: FaceTime Audio) because it has higher quality than cell phone calls. If I'm out and about and want to communicate meeting time/place with someone, I'm going to send (or expect) a text message. So there's the question about whether it's worthwhile continuing to pay for a service that I don't use.

But the real problem is that modern apps and online services use your phone number as if it's a unique ID. If you give some organization your phone number, they'll definitely use it to uniquely identify you. Possibly to third parties.

And, even if you don't give them your phone number directly, since apps can slurp your contact info from any of your friends' contact lists, they've still got it.

And if companies can store this data about you, that data can get hacked and leaked. "HaveIBeenPwned" recently added phone numbers to their search because it's become such a concern.

If you worry about giving out your Social Security number, you should probably worry just as much about giving out your phone number. To companies or your friends.

This doesn't even touch on the problem of spam/phishing/fraudulent calls, which is another real problem w/ the phone system.

So, despite having the same phone number since 1998, I'd love to get rid of mine. Unfortunately, I can't yet because so many systems (ex: banks, messaging apps) do use it to identify you.

Plus, imagine you give up (or just change) your phone number. Now your old number is available for re-use. If someone were to claim it, they could then use it to impersonate you on any systems that haven't been updated with your new (lack of) phone number.

Happy Thanksgiving

I’m thankful for when the cat comes and gets me to come to bed, as if to say: “uh? Hey. I’m sleepy and I need some warm legs to curl up on. Can you get in bed already?” ❤️

Twitter

So recently Elon has:

• Removed twitter identify verification (blue checkmarks are now meaningless?)
• Shut down 2FA
• Removed the information about what app someone tweeted from.

It sure is starting to seem like he paid a lot of money to delegitimize it as a communication platform.

Guess you can't get "cancelled" if people and bots are indistinguishable.

The weather finally got decently cold and we turned on the heat in the new house. Woke up at 3:15am broiling in my own bed. It turns out the previous owner had programmed the thermostat to go up to 75°F at some point in the night.

75!? I barely let the house get that warm during the summer! So I’m currently in the living room with the sliding door to the back patio cracked so I can cool off. 🥵

IDE Inlay Hints

Am I weird in disliking inlay hints?

They're those little notes that your IDE can add to your code to show you what types things are, but they're not actually part of your source code. For an example, see TypeScript v4.4's documentation for inlay hints.

My opinion is that:

• for well-written code, they fill my screen with redundant noise that makes it more difficult to see the simple code in front of me.
• for poorly-written code, they're a crutch that you can rely on instead of refactoring the code to be more readable and less fragile.

As an example, take this code:

function main() {
    console.log(foo("Hello", "world"))
}

// Imagine this function is in some other file, so it's not on the same screen.
function foo(target: string, greeting: string) {
    return `${greeting}, ${target}!`
}

If you're looking at just the call site, there's a non-obvious bug here because the foo() function takes two arguments of the same type, and the author of main() passed them to foo() in the wrong order.

Inlay hints propose to help with the issue by showing you function parameter names inline at your call site, like this:

function main() {
    console.log(foo(target: "Hello", greeting: "world"))
}

(target: and greeting: are added, and somehow highlighted to indicate that they're not code.)

Now it's more clear that you've got the arguments in the wrong order. But only if you're looking at the code in an IDE that's providing those inlay hints. If you're looking at just the raw source code (say, while doing code review, or spelunking through Git history), you don't see those hints. The developer is relying on extra features to make only their own workflow easier.

Without inlay hints, it's a bit more obvious that, hey, the ordering here can be ambiguous, I should make that more clear. Maybe we should make foo() more user-friendly?

Lots of languages support named parameters for this reason. TypeScript/JavaScript don't have named parameters directly, but often end up approximating them with object passing:

function foo({target, greeting}: FooArgs) {
    return `${greeting}, ${target}!`
}

interface FooArgs {
    target: string
    greeting: string
}

Now the call site is unambiguous without inlay hints:

foo({greeting: "Hello", target: "world"})

And, even better, our arguments can be in whatever order we want. (This syntax is even nicer in languages like Python or Kotlin that have built-in support for named parameters.)

The prime use of these kinds of hints is when you're forced to use some library that you didn't write that has a poor API. But IMO you're probably still better off writing your own shim that uses better types and/or named parameters to operate with that library, to save yourself the continued headache of dealing with it. Inline hints just let you pretend it's not a problem for just long enough to pass the buck to the next developers that have to read/modify the code.

Is Windows 11 Just This Slow?

I have a desktop gaming machine that runs Windows 11. It's not bad at games but it's so slow at things like, opening apps, opening settings, etc.

Is Windows 11 just this slow, or is something wrong?

It's so bad that I ran winsat formal to see if my nvme "hard drive" was somehow misconfigured:

Results:

> Run Time 00:00:00.00
> Run Time 00:00:00.00
> CPU LZW Compression                          1139.80 MB/s
> CPU AES256 Encryption                        15057.26 MB/s
> CPU Vista Compression                        2834.34 MB/s
> CPU SHA1 Hash                                10656.56 MB/s
> Uniproc CPU LZW Compression                  100.19 MB/s
> Uniproc CPU AES256 Encryption                986.78 MB/s
> Uniproc CPU Vista Compression                250.19 MB/s
> Uniproc CPU SHA1 Hash                        774.01 MB/s
> Memory Performance                           29614.11 MB/s
> Direct3D Batch Performance                   42.00 F/s
> Direct3D Alpha Blend Performance             42.00 F/s
> Direct3D ALU Performance                     42.00 F/s
> Direct3D Texture Load Performance            42.00 F/s
> Direct3D Batch Performance                   42.00 F/s
> Direct3D Alpha Blend Performance             42.00 F/s
> Direct3D ALU Performance                     42.00 F/s
> Direct3D Texture Load Performance            42.00 F/s
> Direct3D Geometry Performance                42.00 F/s
> Direct3D Geometry Performance                42.00 F/s
> Direct3D Constant Buffer Performance         42.00 F/s
> Video Memory Throughput                      279385.00 MB/s
> Dshow Video Encode Time                      0.00000 s
> Dshow Video Decode Time                      0.00000 s
> Media Foundation Decode Time                 0.00000 s
> Disk  Sequential 64.0 Read                   4159.90 MB/s          9.5
> Disk  Random 16.0 Read                       1007.15 MB/s          8.8
> Total Run Time 00:00:11.67

When it can read a Gagabyte per second when doing random access, I don't think the disk is the problem. The CPU is an "AMD Ryzen 7 3700X 8-Core Processor" at 3.59 GHz, which also shouldn't be a problem.

Anybody have tips beyond "LOL don't run Windows"?

FeoBlog Upgrades

Well, I started this morning fixing a minor bug in FeoBlog. But then the GitHub Action build failed which sent me down a day-long rabbit hole that ended up with me upgrading from ActixWeb v3 to v4.

It's a bit disappointing because Rust is in theory not supposed to break backward compatibility. But I guess some bits of their API leaked and then got used by libraries I was using.

Not really what I had planned for my Sunday but glad to be on newer versions of things, I guess? 😅

Me: You should remain professional and avoid burning bridges.

Facebook recruiter: Hi! Want to use ML to moderate virtual social spaces?

Me: On second thought, …

Fresh Looks Cool!

When Node became popular, I never understood the hype around server-side JavaScript, other than that it took what had before then been mostly client-side and making it usable on the server.

But the pitfalls of writing large systems on the server without type checking seemed too great. And I wasn't that fond of JavaScript at the time.

By the time I got around to playing with Node more seriously, TypeScript was a thing. In FeoBlog I wanted to write a browser-based client that would both be a nice UI and a great demo of the client/server capabilities of the system. I chose Svelte as my UI toolkit, and I very much enjoy the features it offers. However, bundling JavaScript for the browser is still a pain to get working. And if you ship everything as a Single-Page Application, you lose out on indexing, and old/underpowered browsers.

FeoBlog actually has remnants of an early server-side template system which it falls back on for that purpose, but you lose out on a lot of features, and it's lost parity with the new Svelte UI. It would be nice if I could write code once and have it render on the server OR the client.

So now I'm starting to see the appeal of server-side JS. But... I don't really want to run Node. Thankfully there's Deno, which I've already enjoyed writing some scripts for.

AND, there's a cool new web framework called Fresh. It's got the same super-fast dev cycle that I've enjoyed with Deno, and the result is code that can render things on the server OR client.

If you want to see a(n incidental) demo of Fresh, take a look at Deno Deploy: Crazy Fast Cloud Functions - Architecture Speedun, which is where I first discovered it.

Looking forward to see where this goes!