hallettj

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.

It shreds like electric, but it hauls like acoustic

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.

I also use Niri. Previously I basically used maximimized windows on dual monitors. But I really liked the idea of switching to one ultrawide display. Maximized windows wouldn’t work well in that setup. Tiling hadn’t really worked for me because you end up with a screen full of awkwardly skinny or short windows, or windows hidden away in tabs. I also didn’t like the idea of managing floating windows with… a mouse.

So I looked for a better option. I found PaperWM, and I loved it! Exactly what I needed! But it has a number of quirks, being an extension that entirely reworks Gnome’s window management. For a long time I wished for a native scrolling wm. And then Niri came along! And it’s so polished!

Some more points about Nix:

• It’s a fast way to get to a specific setup, like a particular DE or Vulkan gaming support, thanks to abstraction that NixOS modules provide
• There are tons of packages
• Because packages are installed by adding a config entry you don’t accumulate random software you forgot you installed
• Immutable updates and rollbacks - this is similar to benefits of atomic ostree distros, but the nix solutions are more general, so you have one system that does more things with a consistent interface
  • in addition to updating the base system, rollbacks also roll back user-installed packages, and configurations if those are managed via Nix
  • devshells provide per-directory packages and configuration using the same package repos as the host system, without needing to manage docker images
• Nix is portable - much of what it does on NixOS can also be used in other distros, or even on Macos or Windows with the Linux subsystem
  • Configurations often combine NixOS and Home Manager parts. The Home Manager part can be used à la carte on other OSes is a way that is fully isolated from the host OS package management. For example on Macos this is a much nicer alternative to Homebrew.
  • devshells also work on other OSes
• similar to Guix - but NixOS uses systemd, and is (from what I understand) more tolerant of non-free software (whether these are pros or cons is up to individual interpretation)

Arch wiki is the best! I reference often, even though I’m generally applying the information to other distros

My guess was the point is that it’s difficult to install CLI tools using Flatpak

One of favorites cds to the root of a project directory from a subdirectory,

# Changes to top-level directory of git repository.
alias gtop="cd \$(git rev-parse --show-toplevel)"

That’s a helpful one! I also add a function that creates a tmp directory, and cds to it which I frequently use to open a scratch space. I use it a lot for unpacking tar files, but for other stuff too.

(These are nushell functions)

# Create a directory, and immediately cd into it.
# The --env flag propagates the PWD environment variable to the caller, which is
# necessary to make the directory change stick.
def --env dir [dirname: string] {
  mkdir $dirname
  cd $dirname
}

# Create a temporary directory, and cd into it.
def --env tmp [
  dirname?: string # the name of the directory - if omitted the directory is named randomly
] {
  if ($dirname != null) {
    dir $"/tmp/($dirname)"
  } else {
    cd (mktemp -d)
  }
}

Since traditional tiling window management hasn’t caught your interest you might check out Niri, which is a scrolling tiling wm. The differences are that windows always stay the size you set them to, remain in the relative layout you put them in, and you don’t fiddle with layout switching. Niri is also especially mouse- and touchpad-friendly. It’s great for pure keyboard use too - you have both options to suit your preference & mood.

I mention Niri despite it not being what you asked for because it checks all the boxes you listed (apart from stacking), and it’s amazing! https://github.com/YaLTeR/niri

It looks like the setting is max_parallel_downloads in /etc/dnf/dnf.conf. Here’s a post on how to increase it - so do the opposite, and set it to 1.

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.

I’m not sure if I’ve used more in the last 25 years. And when I did I think it was in MS-DOS.

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.