aleyan

If you want to use Iosevka on your webpage there is a variant on google fonts called Iosevka Charon[2] that is really easy to use.

Personally, I use filtered version of Iosevka that just contains the characters and variants I need for my personal website. For HexWalker I filter Sarasa Term to the characters I used, which takes it down to 42kb from 50mb+.

It is kind of shocking to me how TUIs are enjoying a bit of dev tool renaissance right now when the browser is such a capable platform.

The ergonomics of running tasks are very similar to the article as you can run a task simply by typing the name of the task in your shell without saying "make" or "npm run" or whatever else that is the actual task runner. The difference is that you just have to install dela without having to change anything in the underlying project repository.

Works really well for me!

I have done both of these. For the first one[0], I used a Nimslo 3D and for the second one[1] I drew with pastels on paper, and then drew a depth map in Photoshop and used it to displace pixels horizontally for the novel perspectives.

The OP's "accidental" wigglegrams are mostly of the first variety but, the horizontal allignment is not locked in and the shots were taken not at the exact same time. That's why the parallax effect isn't as strong and they don't look as good as the first 3 images that came from Nimso/Nishika.

What is intresting is that both of these two methods are relevant in the age of modern iphone. Iphones capture multiple exposures together in live photos, so moving the iphone laterally when shooting creates a "boomerang" wigglegram. Iphones also capture depth map from the LiDAR sensor when shooting in portrait mode.

Between increased hardware capability and genai for synthesizing additional perspectives, we could be living in a golden age of wigglegrams. Alas, they are out of style.

This quote about robots doing home cleaning has been living in my head rent free, and refusing to cleanup after itself, for over a decade. It seemed so crazy to me in 2015 that anyone would seriously consider home cleaning robots to be on a realistic timeline. Yet here we are in 2026 and robots could plausibly clean our homes beyond vacuuming and mopping.

Humans training robots now completely makes sense to me. I think Sunday Robotics use of people wearing "skill capture gloves" [1] that both capture data and limit range of motion to that of the robotic hands is particularly clever. I wish success to both these and other companies in the space, so that someday soon there will be just a little fewer housework around the house, and we move a bit closer to the Jetsons.

Yes, it makes sense that `uv lock` commands only work the lock file, but users have real needs to upgrade direct and transitive dependencies. For transitive dependencies `uv lock --upgrade-package` works, even if a bit wordy. For direct dependencies, `uv lock --upgrade-package` also works, but doesn't touch `pyproject.toml`, which is much more developer visible. As `uv.lock` package versions get ahead of `pyproject.toml`, `pyproject.toml` becomes a less dependable guide to the surface area of dependencies. A friendly `uv upgrade` command would be nice.

The biggest uv ux footgun I have seen by far is `uv pip`. I have seen a lot of projects use uv correctly with pyproject.toml/uv.lock for development, but then use `uv pip install -r pyproject.toml`, which bypasses uv.lock, in their deployment Dockerfiles and ci tooling. Yes, coding agents are to blame for recommending bad `uv pip` patterns because they have so much `pip` in their training sets, but uv should provide some affordances to protect the user.

Sorry for the rant, uv is a great tool, that I think[0] should be used more! Thank you for your contributions to the ecosystem.

And speaking of agents writing tests, I have an ask. The tests agents love to write are in a lot of ways like human written tests, perfunctory and smelly. They are there to check coverage or prompt checkbox, but they barely stress the system under test. I often find that the tests are faking and mocking so many inputs, methods, and side effects, that they aren't testing anything at all. Asking the agent to write the tests first so that they the underlying implementation is more testable has yielded no results.

What has worked for people to get agents to write more testable implementations and better tests?

PS. Reacting to Uncle Bob, I found metric driven agentic refactors just push complexity to outside the scope of the metric. I am finding I need to actively guide the agents for the refactors to actually improve things without increasing the entropy of the codebase.

Consider the Moon as viewed from NYC at time of comment [0], it is hiding below the horizon. If you were to look at my website and then at the sky you might become upset that I am reporting the shape of the moon, but obviously it can't be seen. Hence why the website reports the angle below the horizon roughly half the time it isn't visible.

Adding Azimuth and Elevation when the Moon is above the horizon would be for completionism only and not the real enterprise use-cases served by ANSI compliant renderings of the Moon.