There are many ways of making wigglegrams. The first method is to capture multiple horizontally displaced shots together at once. There were cameras designed for this in the 80s that had 4 lenses, with the widest about eye width apart; the intent was for them to be printed as lenticular 3d images. The second is to have a single shot and then synthetically create additional perspective, such as by using a depth map.
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.
"I always thought that Homejoy were planning to automate as much as possible, if not everything, related to cleaning services using robotics and stuff, and that humans were only a temporary measure while developing technology." -devgutt 2015 [0]
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.
Agree with you on outdated and upper bounds. However, if users are complaining about the interface being difficult, there is probably something there.
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.
Over on reddit and over here as well people seems to be reacting to the title of the video or the first 5 seconds or just the author. On the original x[1] post however, the top replies are about the subject matter, which is about having agents write tests and refactor code.
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.
1) 2008: pip, 2012: Conda, 2018: Poetry, 2021: PDM, 2023: Rye, 2024: uv. A new package manager every few years rather than every few months would be more apt. But, yes I agree we shouldn't tool churn for newness sake.
2) Have you tried uv? The speed is nice, but is not what makes it shine.
3) uv not being written in python is a defining positive feature for it. It eliminates the bootstrap problem of having to get a system python with the right setup before you can run your python manager, virtualenv manager, and finally package manager. I haven't had to debug anyones virtualenv or python version issues in a year.
Yes, the angle above the horizon is usually what is most useful because it is used to find something small but visible. In the case of my ascii moon, the angle below the horizon, is there to explain why something is not visible. The Moon is large enough that people can easily find it on their own if it is not obstructed by the Earth itself.
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.
This is a fantastic discovery! Displaying azimuth in my ascii-side-of-the-moon [0] sounds useful, but then I would need to explain the symbol. I am displaying altitude/elevation below horizon, but there doesn't appear to be standard symbol for it. I checked the tables linked from article and there doesn't seem to be a symbol for it.
Maybe this is the opportunity to invent and suggest a symbol for Altitude?
Great work! While I was building ascii-side-of-the-moon [0][1] I briefly considered writing my own ascii renderer to capture differences in shade and shape of the Lunar Maria[2] better. Ended up just using chafa [3] with the hope of coming back to ascii rendering after everything is working end to end.
Are you planning to release this as a library or a tool, or should we just take the relevant MIT licensed code from your website [4]?
I have a 24GB M5 macbook pro. In ComfyUI using default z-image workflow, generating a single image just took me 399 seconds, during which the computer froze and my airpods lost audio.
On replicate.com a single image takes 1.5s at a price of 1000 images per $1. Would be interesting to see how quick it is on ComfyUI Cloud.
Overall, running generative models locally on Macs seems very poor time investment.
If you want to get a single entry point into your repo's task, also consider my tool: dela[0]. It scans a variety of task file definitions like pyproject.toml, package.json, makefile, etc and makes them available on the cli via the bare name of the task. It has been very convenient for me so far on diverse repos, and the best part is that I didn't have to convince anyone else working on the repos to adjust the repos structure.
Dela doesn't currently support mise as a source of tasks, but I will happily implement it if there is demand. Currently [1] I saw mise use on 94 out of 100,000 most starred github repos.
Thank you for allowing this moment of self promotion.
The view warrant canaries[0] link on the bottom of the page goes to a cloudflare 502 page. Bitrot is indistinguishable from subpoena, but neither is a good indicator.
Oh man, this is a deep mine to dig. I haven't even thought about svg size optimization. The default blog template I used really wants me to use hero images, and the jpgs are already hefty. I just looked at my network panel, and it seems the font files are loaded once per svg on initial load and then are cached.
What is the motivation for viewbox coordinates being at (0,0)? I have been thinking about setting chart gutters so that the graph is left aligned with the text, but this seems like an orthogonal issue.
I have been using SVGs for charts on my blog for a couple of months[0] now. Using SVGs satisfied me, but in all honesty, I don't think anyone else cares. For completeness the benefits are below:
* The charts are never blurry
* The text in the chart is selectable and searchable
* The file size could be small compared to PNGs
* The charts can use a font set by a stylesheet
* The charts can have a builtin dark mode (not demonstrated on my blog)
Additionally as the OP shown, the text in SVG is indexed by google, but comes up in the image sections [1].
The downside was hours of fiddling with system fonts and webfonts and font settings in matplotlib. Also the sizing of the text in the chart and how it is displayed in your page is tightly coupled and requires some forethought.
I have been excited about bun for about a year, and I thought that 2025 is going to be its breakout year. It is really surprising to me that it is not more popular. I scanned top 100k repos on GitHub, and for new repos in 2025, npm is 35 times more popular and pnpm is 11 time more popular than bun [0][1]. The other up and coming javascript runtime, deno is not so popular either.
I wonder why that is? Is it because it is a runtime, and getting compatibility there is harder than just for a straight package manager?
Can someone who tried bun and didn't adopt it personally or at work chime in and say why?
That's an amazing addition! Once I read about Simpson's paradox[0], couldn't help but seeing it or suspecting it everywhere. Luckily, it is not a true paradox, and it can resolved if underlying data is available and not just summary statistics.
I recommend putting together the Quintet in one image, so that the original 4 charts, plus the new one are all visible and interpretable together. It will be learning aid for decades to come.
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.
[0] https://fooladder.com/post/115435676962/at-the-concert [1] https://fooladder.com/post/61216111704/starry-venice