> We have a blip in March / April every year; these cyclical patterns aren’t relevant to explain here.
The 'blip' post-AI is up ~30% for the months in question. There simply isn't enough data here to prove or disprove the thesis that "customer issues remain broadly stable" - you could equally argue something more along the lines of "AI engineering does not increase issues under ideal conditions but amplifies issues under external pressure."
Friend. You gotta write your own comments. It feels so gross to get a response that’s so obviously from an llm, I would rather you not have replied to me at all. I will not be using your app.
This is a compelling idea, but it doesn't seem to work. Running it on a yml I'm working on currently, it skipped all my setup actions and then failed because the dependencies it needed weren't set up (why did you think I wrote them?) There doesn't seem to be a way to force-run a skipped step.
No, no one has ever known anything, and every day people are born knowing even less. This is a strangely aggressive way to share this interesting information, especially for MacOS programming, a platform requiring such byzantine arcane knowledge I'm amazed people write anything for it at all. At least for Win32 people wrote books you could buy and not blog posts.
Anyway, thank you for the introduction to the very cool SwiftScripting project [0], extracting programmable interfaces directly from app bundles. It's just like COM, right? nice to see MacOS catching up (/ragebait)
Standard always struck me as kind of scummy - it tries to present itself as something bigger than what it really is, which is a tiny CLI wrapper around one guy’s ESLint config. You have to scroll way down the FAQ section before ESLint even gets mentioned. The author is just squatting on the “standard” namespace and using it to blag his way into relevance. Think how much more good it would do if the sponsors of this project were actually supporting ESLint directly instead of this useless middleware.
This is normal, most people are like this. The idea that there’s something out there that you’re just amazing at without even trying very hard is a trap and believing it will destroy your life. You just have to pick something you want to be good at and do it until you are.
I think the specific trap the author is arguing against is where you try to make your classes model 1-1 some external domain model without tailoring them only to the functionally that your specific application needs. If you’re writing a FooClass, it’s easy to get caught up in giving it everything a Foo would have, even if you won’t actually use it.