Exactly one year on from Oniguruma's archival on GitHub and fancy-regex is in a pretty good position to act as a compatible, memory-safe alternative.
Since the previous release, fancy-regex now has support for subroutine calls - although relative recursion level backreferences are still currently unsupported.
There also a PR with an experimental optimization, which may get released soon.
This resonates with me for a couple of reasons. One is that despite a good AGENTS.md file and a detailed, specific prompt, I've seen LLM agents generate all sorts of questionable code. From making a mistake, running tests and fixing the mistake meanwhile adding a comment which only makes sense when you read it from the perspective of having seen it make that mistake... As soon as anyone else would read it, there is no context and it can be confusing or misleading...
Or naming tests only considering the specific task at hand, which is meaningless when compared to the grand scheme of things.
Yesterday I had GitHub ask me to complete a survey on it's Copilot coding agent, and it made me realize that some obvious things were missing from my AGENTS.md. Notes that are unnecessary to be written "normally" because it aligns naturally with how human programmers work. When writing a new unit test in a file full of unit tests, I typically copy an existing test which has roughly what I need, paste it and adapt it. Or at least look at existing tests when building a new one. I've seen LLM agents ignore private helper methods and do full integration style tests for new test cases because they don't work like that unless specifically instructed...
So yes, I definitely feel that AI can increase tech debt big time unless managed carefully - paved roads are the way to go for human developers and AI agents. It does get tricky when you need to branch out and do something new or never considered before though...
I personally really enjoyed this article - thanks for sharing.
I have worked for companies which use OKRs to help decide what they want to achieve, but it was never clear to me how they decide what features to implement to reach those goals.
Seeing the "impact, confidence, and ease scores (ICE)" concept and how it should be done is quite an eye opener for me. Maybe that has been done where I work, just never shared with me - a lowly senior developer, who knows...
I tried using Mergiraf a year or so ago, and ended up with so many weird problems that I eventually tracked down to being caused by it, that I disabled and uninstalled it and never looked back - it was more hassle than it was worth
Having to pipe to a pager - to follow the unix philosophy - means:
- extra typing each time
- the pager receives static output. There is no interactivity... Sure, most pagers can search. But there is no way to have a table with adjustable columns, or toggle word wrap or line numbers etc.
I feel that for a tool like bat, it is better to have it built-in and not follow the composable philosophy because it is just so much more convenient.
Of course the minus integration in bat is fairly basic at the moment, I guess supporting different code paths for static pagers vs interactive would increase maintenance burden quite a lot...
git itself has no concept of branch policies, it is purely a server side thing. But surely it doesn't really matter what branch you commit to locally, if you can't push it, you haven't done any damage and can just create a new branch and push that instead?
Isn't that what branch policies are for? It can get annoying when making a release (from a local machine as opposed to automatically in CI/CD pipelines), but in other circumstances it serves the purpose very well in my experience
The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit.
It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me.
I have had tools break things before and it makes it very hard to work out what happened.
Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.
> Another area where you can lean a lot more heavily on HTML is API responses
Please no - it is so much nicer and easier when using a website with poor UI/filtering capabilities/whatever, to look at the network requests tab from devtools in the browser and get json output which you can work with however you want locally versus getting html and having to remove the presentation fluff from it only to discover it doesn't include the fields you want anyway because it is assuming it should only be used for the specific table UI...
Plus these days internet while out and about isn't necessarily fast, and wasting bandwidth for UI which could be defined once in JS and cached is annoying
And if you come back to this script in a few years time and it pulls a newer version of numpy with an incompatible api, there is no easy way of knowing which version it was designed to be used with...
I really like how clear and well laid out these rules are. It covers lots of things that I have always thought about when I write instructions in README files etc, so it's very nice to see everything neatly described/reasoned in one place. Thanks for sharing!
I tried this out, and nothing happened. Then I discovered that it has to be enabled first, for example by: https://unix.stackexchange.com/a/34251/152147
Thanks for sharing, learnt something new :)
The problem here is that new features often involve some refactoring work. Then, if you didn't opt for feature X, the company isn't going to go out of their way to make and ship and maintain a fix for the old non-refactored version, so if you want fixes, there is no way to get them without feature X... Unless they are using feature flags of course, but then no fixes/updates are exactly "safe" for the combination of features agreed to.