My work is using Coderabbit, and I’ve found its feedback to be pretty helpful - especially since I’m working with a language I don’t have a whole lot of experience with (Python). I check what it tells me, but it has taught me some new things. I still want human reviews as well, but the AI can pick up on detail that is easy to skim over.

It doesn’t cover bigger picture stuff like maintainability, architecture, test coverage. Recently I reviewed a PR that was likely AI generated; I saw a number of cases where logic duplication invited future bugs. (Stuff like duplicating access predicates across CRUD handlers for the same resource, repeating the same validation logic in multiple places.) Also magic strings instead of enums, tests of dubious value. Coderabbit did not comment on those issues.

I’m also getting feedback from Sonarqube on the same project, which I think is static analysis. It’s much less helpful. It has less to say, and a lot of that is pointing out security issues in test code.

Me too, but I sometimes access my Obsidian notes in Neovim using obsidian.nvim. If I’m doing substantial editing it’s nice to have my usual editor. And then the experience is pretty similar to VimWiki.

Fugitive, the vim / neovim plugin. It does everything the CLI does, but uses vim interfaces very effectively to enhance the experience. For example it’s quite good for selectively staging changes from a file. I also like the option to open a buffer with the version of a file from any specified commit.

I also tried neogit which aims to port magit to neovim. I didn’t like it as much. Partly because as far as I could tell at the time it lacked features compared to fugitive. But also because it seemed to want me to do everything through UIs in its own custom windows. Fugitive is integrated more thoroughly into vim via command mode, and special buffers.

I usually use git add -p to selectively stage hunks. But in git add -i I think running the patch command does the same thing to get into patch mode.

If patch mode shows you a hunk, and you only want some of the lines you can press s to split into smaller hunks. Then you’ll be prompted whether to add each smaller hunk separately.

If you want to stage a change that is on the same line as a change you don’t want to stage, or on an adjacent line, then you need to use e to edit the hunk. Git stages whatever changes are left when you’re done editing. The file in the working tree on disk is unchanged.

That makes sense. I didn’t find many surveys available, so I referenced the ones I could find.

It’s hard to predict the future, but I can point to a couple of indexes.

TIOBE measures language popularity according to a variety of factors. It has Java on a steady downward trend over the last couple of decades, but shows it as still very relevant. TIOBE does not show comparable growth for Golang. I don’t see much growth in the top 10 for languages that are especially suited to autoscaling. C# looks to be steady as a language in a similar niche as Java.

OTOH another survey from devjobsscanner that looks purely at job postings shows Java openings as very steady over the last couple of years. It also shows Java as more popular than Golang.

So I don’t know exactly what conclusion to draw from that. But learning a new language can be a helpful exercise regardless to broaden your perspective, and to keep your skills sharp.

Personally for the purpose of producing resource-efficient binaries for scaling I prefer Rust. It’s design incorporates some correct-by-construction strategies that promote high-quality code. And it’s well-suited for compiling to WASM so you can do stuff like deploy small services to Cloudflare workers for wild scaling. But I guess Rust isn’t making a big showing in the popularity charts. And Golang is popular for its lower learning curve.

If you’re getting started with programming the first resource I point people to is Scratch. It’s the easiest way to get started, and teaches programming concepts with guide-rails. I recommend looking at a game someone else has made on the Scratch website, and “remixing” it to tinker, and understand how it works.

When you hit the limitations of Scratch, and want more I agree with other commenters that Godot or LÖVE are good next steps.

Maybe the bubble rings are like the psps sound people make to cats - which is another behavior that appears unrelated to feeding, mating, or defense

The images probably don’t have to look meaningful as long as it is difficult to distinguish them from real images using a fast, statistical test. Nepenthes uses Markov chains to generate nonsense text that statistically resembles real content, which is a lot cheaper than LLM generation. Maybe Markov chains would also work to generate images? A chain could generate each pixel by based on the previous pixel, or based on neighbors, or some such thing.

For the sake of benefit of the doubt, it’s possible to simultaneously understand the thesis of the article, and to hold the opinion that AI doesn’t lead to higher-quality products. That would likely involve agreeing with the premise that laying off workers is a bad idea, but disagreeing (at least partially) with the reasoning why it’s a bad idea.

Yeah, the article seems to assume AI is the cause without attempting to rule out other factors. Plus the graph shows a steady decline starting years before ChatGPT appeared.

I use obsidian.nvim. It’s a Neovim interface to my Obsidian vaults, so I can work on my knowledge base in whichever app works best in the moment.

It seems to me that you’re asking about two different things: zero-knowledge authentication, and public key authentication. I think you’d have a much easier time using public key auth. And tbh I don’t know anything about the zero-knowledge stuff. I don’t know what reading resources to point to, so I’ll try to provide a little clarifying background instead.

The simplest way to a authenticate a user if you have their public key is probably to require every request to be signed with that key. The server gets the request, verifies the signature, and that’s it, that’s an authenticated request. Although adding a nonce to the signed content would be a good idea if replay attacks might be a problem.

If you want to be properly standards-compliant you want a standard “envelope” for signed requests. Personally I would use the multipart/signed MIME type since that is a ready-made, standardized format that is about as simple as it gets.

You mentioned JSON Web Tokens (JWTs) which are a similar idea. That’s a format that you might think you could use for signing requests - it’s sort of another quasi-standardized envelope format for signed data. But the wrinkle is that JWTs aren’t used to sign arbitrary data. The data is expected to be a set of “claims”. A JWT is a JSON header, JSON claims, and a signature all of three which are serialized with base64 and concatenated. Usually you would put a JWT in the Authorization header of an HTTP request like this:

Authorization: Bearer $jwt

Then the server verifies the JWT signature, inspects the “claims”, and decides whether the request is authorized based on whether it has the right claims. JWTs make sense if you want an authentication token that is separate from the request body. They are more complicated than multipart/signed content since the purpose is to standardize a narrow use case, but to also support all of the features that the stakeholders wanted.

Another commenter suggested Diffie-Hellman key exchange which I think is not a bad idea as a third alternative if you want to establish sessions. Diffie-Hellman used in every https connection to establish a session key. In https the session key is used for symmetric encryption of all subsequent traffic over that connection. But the session key doesn’t have to be an encryption key - you could use the key exchange to establish a session password. You could use that temporary password to authenticate all requests in that session. I do know of an intro video for Diffie-Hellman: https://youtu.be/Ex_ObHVftDg

The first two options I suggested require the server to have user public keys for each account. The Diffie-Hellman option also requires users to have the server’s public key available. An advantage is that Diffie-Hellman authenticates both parties to each other so users know they can trust the server. But if your server uses https you’ll get server authentication anyway during the connection key exchange. And the Diffie-Hellman session password needs an encrypted connection to be secure. The JWT option would probably also need an encrypted connection.

Always a good one! It seems overdue for an update to include Clojure, Go, Rust, Typescript, Swift, and Zig.

This seems like a restatement of X. We still don’t understand Y. I’m especially confused about:

• Why are SHA-256 and friends ok, but IPFS CIDs are not? They have basically the same functionality.
• Do you need a distributed network, or is a single server ok?

There was some hint that maybe you’re concerned about reproducibility for CIDs? If you fix the block size, hash algorithm, and content codec you’ll get consistent results. SHA-256 also breaks data into chunks of 64 bytes as it happens.

Anyway Wikipedia has a list of content-addressable store implementations. A couple that stand out to me are git and git-annex.

I’ve mainly worked as an employee so I don’t have as much experience with freelance gigs. But nearly every job I’ve had in 18 years has been through networking. Organizing and speaking at programming meetups opened a lot of doors for me. It gets a lot of attention on me while I get a chance to present myself as an expert.

Eventually I’d worked with enough people that when I’ve been looking for work I find I know people who’ve moved to new companies that are hiring.

We live in a capitalist society. Most of Typst is open source including the CLI, library, and IDE support; and the source is Rust so why not share in a Rust community?

I’ve been using nushell as my shell for a long while. Completions are not as polished as zsh - both the published completions for each program, and the UX for accepting completions. But you get some nice things in exchange.

I LOVE using nushell for scripting! CLI option parsing and autocompletions are nicely built into the function syntax. You don’t have to use the shell for this: you can write standalone scripts, and I do that sometimes. But if you don’t use it as your shell you don’t get the automatic completions.

Circling back to my first point, writing your own completions is very easy if you don’t like the options that are out there. You write a function with the same name as the program you want completions for, use the built-in completions feature, and it’s done.

If the return type of a function is NonEmpty the value returned is guaranteed to be non-empty because it is not possible to construct an empty NonEmpty value. That’s the “make illegal states unrepresentable” mantra in action.

At runtime you might get a list from an API response or something, and it might be empty. At that point you have a regular list. Following the advice from the article you want to parse that data to transform it into the types representing your legal states. So if the list is not supposed to be empty then somewhere you have a function that takes the possibly-empty list, and returns a value of type NonEmpty. But if the list actually is empty that function will fail so it has to be able to return or throw an error. The article uses the Maybe type for that which is one of the Haskell types for functions that can fail.

Once you have parsed the input list, and successfully gotten a NonEmpty value the rest of your code can safely access the first element of the list because a value of that type is guaranteed to have at least one value.

Hey I had this post in mind just yesterday when I was working on some Mastodon client code to show comments on my static-site blog. Typescript is especially well-suited for deriving types from parsers. I also enjoyed brushing up on how to use JSDoc annotations and ES modules to publish what is effectively Typescript that runs in the browser without a build step.