The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation.
That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back.
As a nice bonus, this pattern gives a good answer to the problem of having "if dry_run:" sprinkled everywhere: You have to separate the planning and execution in code anyway, so you can make the "just apply immediately" mode simply execute(plan()).
I've split the process into three parts:
1. Walk the filesystem, capture the current state of the files, and write out a plan to disk.
2. Make sure the state of the files from step 1 has not changed, then execute the plan. Capture the new state of the files. Additionally, log all operations to disk in a journal.
3. Validate that no data was lost or unexpectedly changed using the captured file state from steps 1 and 2. Manually look at the operations log (or dump it into an LLM) to make sure nothing looks off.
These three steps can be three separate scripts, or three flags to the same script.
It's slightly larger in the US at 5.28%: https://gs.statcounter.com/os-market-share/desktop/united-st...
In India, where I live, it's surprisingly at 6.51%: https://gs.statcounter.com/os-market-share/desktop/india
Take this with a grain of salt, because numbers from Statcounter are not fully accurate. However, none of those numbers are small. 3.86% of the entire PC market is not something to scoff at.
Stopped using python for scripting for this reason
I've started using Python for many more tasks after I discovered this feature. I'm primarily a JS/TS developer, but the ability to write a "standalone" script that can pull in third-party dependencies without affecting your current project is a massive productivity boost.
While I personally like it when people put their heart and soul into something, even if the result is technically not very great, it's society who is the ultimate judge of whether that creation benefits them or not.
I know that the track I'm currently listening to is superior in every way to some modern pop song. The artists have practiced for decades, they have their own unique style I can recognize in other tracks. But I also know that 99.999% of people don't give a shit and think it's noisy music, and depending on your perspective, they're correct.
I can imagine that this is true for a lot of people. There are certainly folks out there who see music as an interesting sensory stimulus. This song makes you dance, this one makes you cry, this other one makes you feel nostalgic. To these people, the only thing that matters is what the music makes them feel. It's a strange, solipsistic way of engaging with art, but who am I to judge?
I personally don't connect to music—or any other art—that way. The process that goes into making a piece of music is as important to me as the music itself. The people who make that music are even more important. I don't believe in separating art from the artist. In fact, I find the whole idea of separating art and artist to be fundamentally rotten.
Here's an admittedly extreme example, but it's demonstrative of how I personally relate to music. In the wake of the #MeToo movement (see https://en.wikipedia.org/wiki/MeToo_movement), some of the musicians I used to love as a teenager were outed as sexual predators. When I found out, I scoured my music library and deleted all their work. The music was still the exact same music I fell in love with all those years ago, but I could no longer listen to it without being reminded of the horrible actions of the musicians. Listening to it was triggering.
And so to me, music is not just a series of sounds that make me feel good. There are humans behind those sounds, and I care deeply about those humans. They don't need to be perfect—everyone fucks up from time to time—but they need to demonstrate some level of human decency. And they certainly can't be machines, because machines aren't people.
I love machines. I've spent my life building them, programming them, and caring for them. But machines aren't people, and therefore I don't care about the art they make. Maybe one day machines will be able to make art in the same way humans do: by going out into the world, having experiences, making mistakes, learning, connecting with others, loving and being loved, or being rejected soundly, and understanding deeply what it means to be a living thing in this universe. A generative AI model doesn't do that (yet!) and so I'm utterly uninterested in whatever a generative AI model has to say about anything.
They can, but the major providers (read: the ones I would trust to update it) don't. The IERS doesn't [0], the USNO doesn't [1], IANA doesn't [2], and NIST uses FTP [3]. Keep in mind that these files are constantly being downloaded by various clients for NTP and whatnot, it's not like these providers want to restrict public access, they just don't bother to set the header that would allow JS requests.
> Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file.
From ECMA-262:
> It is required for time zone aware implementations (and recommended for all others) to use the time zone information of the IANA Time Zone Database https://www.iana.org/time-zones/.
Any browser that ships with a copy of tzdb, or knows where to find a copy from the OS, should have access to its leapseconds file. Unless you mean that all of them go solely through ICU and its data files? Which I suppose could be an obstacle unless ICU were to start exposing them.
[0] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
[1] https://maia.usno.navy.mil/ser7/tai-utc.dat
[2] https://data.iana.org/time-zones/tzdb/leap-seconds.list
[3] ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list
You could even write a Cloudflare Worker or a Val on val.town to do that, and add a bit of caching on top so you don't hit your providers too often.
If you allow Markdown input you have to give a cheatsheet showing which "flavor" you are using.
This sucks for sharing documents with other people, but in practice it's not a problem. 99% of my writing never leaves my notes app or blog. And when it does, I often export it to PDF or Word to make it easy for non-techie people to read (I love Pandoc for this, it's easily one of the favorite tools in my daily toolkit).
it's like YAML: it looks so simple at first, and then the horrors start if you try to use it seriously.
in both cases the most horrors lie in the spaces/tabs/newlines.
I agree entirely. But it's a lovely format to use. Programming as a profession is entirely about making things easier for our users, even if it means making things harder for ourselves.
After all, that's the whole ethos around the web as a platform. Throw some broken HTML soup at a browser and it'll still try its best to render it.
Remote: preferred
Willing to relocate: no
Technologies: web platform (HTML, CSS, JavaScript), the React ecosystem, TypeScript, Tailwind, Astro. Good enough at UI/UX design to be dangerous.
Résumé/CV: https://ankursethi.com/work/
Email: contact@ankursethi.com
I'm an independent consultant and frontend engineer helping startups (and a few large organizations) bring new products to market since 2012.
I can help you with:
- Building an MVP of your product to put in front of investors and early adopters.
- Overhauling existing products by adding major new features, fixing performance bottlenecks, or paying off tech debt.
- Helping your team get up to speed with emerging technologies (currently interested in helping with TypeScript, modern React, the Jujutsu VCS, and LLM-driven programming).
- Modernizing legacy products and migrating them off legacy tech stacks.
- Acting as a bridge between your design and engineering teams.
I'm primarily a frontend developer comfortable with vanilla HTML/JS/CSS as well as more complex frameworks (mainly React, but I've worked with others). I enjoy being a heads-down technical contributor to codebases. However, working with early-stage companies has allowed me to dabble in UX design, hiring, mentoring, technical writing, technical workshops, and product design. I enjoy wearing a ton of hats, and prefer to work at orgs that allow me to use the full set of my abilities.
I enjoy using LLMs, but I do so responsibly. I write regularly at https://ankursethi.com/.
I'm currently looking for short to medium term contracts (think 6-8 months).