I'm experimenting with jj this weekend. It seems pretty nice so far, but the mental model is pretty different from git.
For example, there's no `checkout` command. You do `jj new ABC` to switch to a commit, which creates a new empty commit on top of ABC.
miniblog.
I've just squeezed another 5% of performance out of difftastic by finding a few HashSet values that weren't FxHashSet.
I do wonder whether hash DoS resistance is a good default. Sure, Rust programs are often pretty fast anyway, but it feels like a different threat model to the rest of Rust.
I'm experimenting with live-evaluating tests in my programming language project.
It's relatively fiddly to hook up a UI for this, but it saves a precious keystroke to run the tests! I'm hoping that it results in more, better tests due to the convenience.
I'm experimenting with Atuin for searching my terminal history: https://atuin.sh/
Previously I'd just used fzf to find items, which does work nicely. Occasionally I *really* want to search "commands which were run in this directory" though, which Atuin offers.
I have a bunch of open tasks on my GH repos, so I tried asking ChatGPT and Claude to write a card-based web UI that showed some random open issues.
ChatGPT gave me something that worked, but the Claude mock-ups look better (and render inline!).
"Example Driven Development" using Glamorous and Pharo Smalltalk: https://medium.com/feenk/an-example-of-example-driven-development-4dea0d995920
Tests returning values and composing is a really interesting model. It establishes structure and shows which test failure is the most 'fundamental'.
TIL Advent of Code and Project Euler will deliberately look for puzzles where the naive solution is worse than quadratic.
This ensures that people can solve them with any programming language. You don't want fast languages to be able to use the naive solution.
Today I learnt that `cargo fix` won't fix code with compiler errors by default, but you can override this!
$ cargo fix --broken-code --allow-dirty && cargo clippy --fix --allow-dirty
This incantation does exactly what I wanted :)
The games console market is fascinating: there's incentive to *not* provide upgraded models.
You want the guarantee that a game for $X just works on any $X purchased.
E.g. the Switch OLED has a bigger screen, and a better CPU than the original, but it's downclocked to match the original Switch's CPU.
Go has an elegant approach to defining example functions, which are shown in docs as `main()` with the output: https://go.dev/blog/examples
I find it really interesting how some areas of tech are widely expected to improve radically (e.g. LLMs and smart home tech), others gradually (CPU speed, battery capacity) and others very slowly (e.g. compiler optimisations).
Predicting the future is hard.
A pleasant surprise: updating the direct dependencies in difftastic has reduced the total transitive dependencies. I wasn't expecting that.
It feels like a mature software project is one where bugs require multiple commits to fix.
You've hammered out the basic issues, so the remaining issues are often weird interactions between components.
Showing 101-113 of 113 posts