jez

This is the first I’ve heard the point that it’s hard to give employees equity at EU-based startups.

- If you’ve worked in tech in the EU, can you share examples of this affecting you?

- Does this also extend to US companies that want to give equity to EU-based employees?

The Memory Usage on Benchmarks section shows CRuby as one of the bars. It is the lowest across the board. YJIT, being implemented in CRuby, uses at least as much memory as CRuby in all the benchmarks (you could maybe imagine one day JIT’d code using less memory in specific situations by compiling code to a more efficient algorithm that skips allocations the interpreter would make, but it appears that is not the case yet today).

Hold option and click on the “collapse file” button in the Files view of a commit or pull request, and it will collapse all the files.

Select text in a comment, issue, or pull request description and press r—the selected text (including markdown formatting) will get pre-populated as a markdown block quote reply in the next comment box.

Add .patch or .diff to any pull request URL if you want to see a plain-text diff of the pull request (e.g. maybe you want to quickly `curl ... | git apply -` an unmerged pull request into a local copy of the repo without trying to add and fetch the git remote that the pull request is from).

There are lots of keyboard shortcuts. For example, / to jump to the file finder.

Not so much a secret but more like a hiding in plain sight: when looking at a commit GitHub will show you the earliest and latest tag (i.e. release) that includes the commit. For example, this commit[1] first appeared in v3_2_0_preview3.

[1]: https://github.com/ruby/ruby/commit/892f350a7db4d2cc99c5061d...

A problem with this approach is that deleting a file from source/ does not delete it from build/.

In my own projects, simply rebuilding the whole site is fast enough, so I opt to remove the whole build folder before a rebuild:

https://github.com/jez/jez.github.io/blob/source/Makefile#L1...

This defeats a big part of why you’d want a build system in the first place (incremental builds), but at least if you know the page you want to regenerate you can still `make` that file directly.

If there’s a common workaround for this pattern in makefiles I’d love to learn it.

Am I correct in understanding that this means you can only have a list of typed ASTs, or a list of not-yet-typed ASTs, but not a list with a mix?

Obviously I understand that if this is the limitation, then there are ways to work around this, and it all depends on how annoying the workarounds are.

But I’m curious is there a trick that allows it. All the tricks I can think of involve boxing the the ASTs you’re about to store in the list (which then come with memory/performance hits), and I’d love to be proven wrong.

Your solution is the second alternative proposed in the article: the “Nullable field” solution.

It’s an example of a classic tradeoff between enforcing correctness and invariants “by construction” vs at runtime. Since the field is nullable, the AST is not necessarily correct by construction, as the programmer may have forgotten to include a type when required. The correctness of compilers using such representations involves either checked or unchecked assertions where the type field is used to ensure that it is set appropriately.

The article continues with various strategies to avoid needing to defer this correctness checking to the runtime by providing various statically-checked alternatives.

No, the default Homebrew install location moved to /opt/homebrew on new Apple Silicon Macs.

(I don’t know why Intel Macs still use /usr/local.) In any case, it’s possible to choose a custom installation location, even on Intel Macs if you prefer.

https://docs.brew.sh/Installation

Further discussion on the decision:

https://github.com/Homebrew/brew/issues/9177

They also have a paper on the approach, though it doesn’t seem linked from the repo.

https://dl.acm.org/doi/pdf/10.1145/3586057

4. Attempt to intercept network requests, so you can prompt the user with whether they want to continue running the command, or abort the connection.

It seems that the focus is on sandboxing file system access. This is great if you already know that “stateful disk access” is the only thing the command does!

It would be interesting to think about how/whether to extend this to stateful network access. What would happen if I used try on a command that does something like create a GitHub pull request? Right now I believe the pull request gets created regardless of whether I commit the file system changes at the end. Some alternatives:

1. Block all network access, because the tool can’t reliably reason about what could be happening.

2. Block all network access, except accesses that look like HTTP GET requests (and maybe HEAD/OPTIONS requests).

3. Attempt to build some sort of request replay mechanism, so that if a command’s results aren’t committed, but the command is ~immediately re-run with slightly different options, HTTP responses for requests identical to those from the previous attempt are re-used without making the request a second time.

Obviously all three have downsides in terms of how useful/complex/brittle they make the command. But maybe worth pondering at the least.

> I sincerely hope this might make Chrome change its mind.

I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day?

If the decision was intentional: did they state a reason why?

You're seeing the dark theme for the site. (I see the same thing when I click the checkbox in the top right corner of the page as when I disable JS.) Perhaps it's using JavaScript to detect that your browser is reporting that you prefer light-mode sites?

Admittedly, the site could probably use CSS to make this decision as well, but I figured I'd mention it.

I’m sold, anyone want to share their favorite bean dishes?

They also have a paper on the approach, though it doesn’t seem linked from the repo.

https://dl.acm.org/doi/pdf/10.1145/3586057

Importantly, the point doesn’t also say publish them while you’re still learning them. I think maybe there’s an argument for writing early both as a tool to learn a topic (the parts where the argument is weak you need to learn more!) and as a way to have empathy for a beginner audience (you’re the audience!). Neither of these imply needing to publish the post immediately. You could hold onto it for some time, shop it around to friends or coworkers with more experience, etc.

I also agree with the point, because I find there are so many things I want to write about as I’m learning them, but I’ll say “ah, let’s hold off for just a bit” but by the time I feel like I know enough to truly put out a good post, I’ve lost the learner’s spark and enthusiasm I had when first had the idea for a post.

In my experience (Bazel, sample size of 2 projects), the complexity doesn't come from configuration options that have defaults, but from how well the "mental model" of the build system fits the preconceived notions of how to structure, organize, and depend on code in an existing project.

Almost none of the complexity comes from what configuration options I've registered ahead of time. It comes almost entirely from, "Well darn, this code depends on this completely unrelated part of the project. I wish it didn't, but now the build tool either needs to sometimes fail to rebuild something correctly, or it needs to build way too much to run quickly."

One of the custom emoji I use the most is a picture of a judge’s gavel mid-swing. It’s useful to convey the finality of a decision that’s been made. There’s a judge emoji where the judge is holding a gavel, but it doesn’t quite work the same way. If I were going to ask the committee for one emoji, this would be it.

A lot of people are taking this as yet another example of Dropbox changing things for no reason, but I think it’s important to make clear that in this case Apple is forcing their hand. Dropbox is being told by Apple that apps must integrate with File Provider API[1] if they want to present files that don't exist on disk until they’re first opened.

This API is hamstrung and limiting, full of instabilities and quirks (designed to fit iCloud primarily but not necessarily everyone else).

In my opinion, the fault lies with Apple here.

[1] https://developer.apple.com/documentation/fileprovider

(Full disclosure: I interned at Dropbox for 3 months 8 years ago.)

I'd also love a poison oak visual quiz! Something I learned recently is that poison ivy isn't native to California—it's three variants either grow in Asia, the eastern US, or "not California." [1]

[1] https://en.wikipedia.org/wiki/Poison_ivy

Every debate you lose is one where someone else won (and by the author’s logic, was deprived of the chance to lose).

Some debates I want to win, for the simple joy of teaching someone something new.

While it would be an optimal use of my time (from an information-theory point of view) for me to lose every debate I participate in, some debates are worth taking up for the chance to share.

What about the gaps makes it more obvious which window is focused? I would have guessed that the gaps are the same for focused and non-focused windows.

If you want to get a sense for the scale of the flooding, KPIX CBS put out a video with a lot of shots, from the Mission to Fisherman’s Wharf, 101 and 280, Walnut Creek, San Ramon… wild to see flooding like this everywhere:

https://youtube.com/watch?v=zCuKgorawck

Hoping people have managed to keep safe and dry.

Two things happened in my first week:

- Using the iOS Safari share button to “Open in NetNewsWire” would silently fail if the blog didn’t have a feed. I went looking for my feeds later and they were missing. I tried a few more times before realizing, “oh, there’s just no feed.”

- Some sites I found had multiple feed links (one per kind of post: long post, short fragments, photo posts). NetNewsWire would always pick the first link in the page, disregarding all others, and not telling me that the page had multiple.

We can say “discovery is not a problem” but I don’t think it’s unreasonable to ask for it to be better. Half the value proposition of sites like Substack is making it dead simple for readers to understand how they can subscribe.

As someone who had never used RSS before and didn’t know how to expect RSS to work, it was the problem that grated me the most. If discovery isn’t seamless, only the people determined to use RSS will stick with it after their friends pester them to try it out.

To underscore this comment: by simply enabling GitHub pages on a GitHub repo, it will automatically render Markdown to HTML as soon as you push the repo.

If you want, you can layer on Jekyll and a custom theme down the road—but if you know how to write Markdown in a GitHub repo, you can have a blog live in 2 minutes, and then get started on those articles you mention are already in your head.

Depending on what peripherals you already have, something that has been working well for me is using a cheap MacBook Air to ssh into a custom-built desktop PC running Linux under my desk. For work you probably care more about memory and CPU power (vs the PC gamer who cares about a big graphics card). So for $1000 you can get an M1 MacBook Air and with the other $1000 you can buy components for a 12 or 16 core desktop.

SSH over LAN (while you’re at hone) is much snappier than you’d expect if your only experience with SSH is to an AWS data center. Slap Tailscale on both machines, and now you can access the home PC from anywhere on the road. Heck, you can even access it from a phone in a pinch with a mobile SSH client.

With this setup you get native macOS and Linux (no docker nor VM required), power, portability, and battery life. It’s not the best solution for everyone but it’s working pretty well for me.

MJIT pastes together snippets of C code that implement Ruby VM bytecode instructions. It then hands off that C code to GCC which compiles it to native code while the Ruby VM is running.

YJIT compiles from Ruby VM bytecode straight to native code using a JIT technique called basic block versioning (which is slightly different from how JITs like V8 work because the unit of reuse is a basic block instead of a function).

There’s more information in these links:

https://youtube.com/watch?v=zO9_uTaELCw&feature=shares

https://shopify.engineering/yjit-just-in-time-compiler-cruby

In the past, another tool I’ve used is this bash script that interacts with Spotify over dbus:

https://gist.github.com/wandernauta/6800547

It’s nowhere near a fully featured Spotify client, but for little scripts or UI things where I just want to see the current song it’s pretty lightweight and already works with the Spotify app I have installed (obviously this means it has a different end goal in mind than Spotifyd).

I enjoyed this 3-minute video from The Metals Company YouTube channel a bit better than this press announcement for learning about what this company is and what they're trying to do:

https://www.youtube.com/watch?v=Ib4azYzQY9k

“Sublists must have surrounding blank lines” and “HTML has to be wrapped” is enough to be annoying IMO. Again, not insurmountable but just the sort of thing that I’d find weird looking every time I authored a djot doc.

Especially the blank lines around lists restriction. The syntax goes to explain how “tight” lists do not have their elements wrapped in paragraphs, while “loose” lists do. This admits that lists in the rendered output will want to use whitespace to achieve a particular layout. But for the case of a Markdown list like this, which will be rendered with no whitespace between items:

    - top
      - inner
    - top
      - inner
    - top
      - inner

In djot this must become:

    - top

      - inner

    - top

      - inner

    - top

      - inner

which has way more whitespace in source form than the rendered output will have. This makes it harder to judge the visual weight of a piece of text by simply glancing at the source, and would require spending more time looking at the rendered output while drafting.

And to go further, a loose list would require even more whitespace:

    - top


      - inner


    - top


      - inner


    - top


      - inner

If there were a way to relax this constraint about new lines for list sub elements, I might even consider switching to this for some documents today, but absent that it’ll have to be once I bang into a few more markdown ambiguity problems.