Seems like repopack only packs the repo. How do you apply the refactors back to the project? Is it something that Claude projects does automatically somehow?
The numbers are debatable as usual but they're not taken from thin air
> A 2023 survey conducted by Payroll.org highlighted that 78% of Americans live paycheck to paycheck, a 6% increase from the previous year. In other words, more than three-quarters of Americans struggle to save or invest after paying for their monthly expenses.
> Similarly, a 2023 Forbes Advisor survey revealed that nearly 70% of respondents either identified as living paycheck to paycheck (40%) or—even more concerning—reported that their income doesn’t even cover their standard expenses (29%).
The numbers are debatable as usual but they're not taken from thin air
> A 2023 survey conducted by Payroll.org highlighted that 78% of Americans live paycheck to paycheck, a 6% increase from the previous year. In other words, more than three-quarters of Americans struggle to save or invest after paying for their monthly expenses.
> Similarly, a 2023 Forbes Advisor survey revealed that nearly 70% of respondents either identified as living paycheck to paycheck (40%) or—even more concerning—reported that their income doesn’t even cover their standard expenses (29%).
I don't read it as _bypassing tests_. They have tested the interpreter (`template type`) when it was first released, and they have _validated_ the new template instance (via `content validator`) and assumed this is enough, because it was enough in the past. None of the steps in the usual process were bypassed, and everything was done by the (their) book.
But it looks to me there's no integration test in the process at all. They're effectively unit testing the interpreter (template type), unit testing (validating) the "code" (template instance), but their testing strategy never actually runs the code on the interpreter (or, executes the template instance against the template type).
> Why don't you grow your own food? Why don't you just write your own payment processor?
I find that usually if someone says "why don't X _just_ do Y", they haven't really considered what it takes to _just do Y_. Similarly,
> I know the UI/UX isn't the best, but that could probably be fixed pretty easily
could be expanded into 50 points of why exactly it wouldn't be _pretty easy_ to to "fix IRC UI/UX".
Honestly I don't know what answer OP expected here. If it's easy to set up/maintain Slack alternative based on IRC, with fixed UI/UX and appropriate for _most companies_, they should simply start a Slack competition for half the price and rake the profits, I guess
I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions.
Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL queries makes little sense. But for internal APIs, whitelisting whatever queries current clients need isn't any less convenient
A while ago I went into a rabbit hole looking for something to support my hunch (which I now confirmed by installing old macos) and found some discussions about graphics/OpenGL APIs being deprecated and removed over time. I have a very uneducated guess that new-macos-on-old-hardware runs some translation for all graphics operations/APIs, which causes perceptible lag when doing _anything_, because everything draws on the screen. It does feel as if the OS is constantly struggling with some background tasks
> Software just becomes larger and more complex and thus slower on older hardware.
So every major OS update is larger and more complex, so it's to be expected that after ~4 of those my machine lags when doing literally everything? It's not that I'm running tons of background apps, it's a powerful machine lagging on a clean install of a recent macOS version when doing basic operations like opening a webpage.
> My 2021 MacBook Pro 14" is still lightning-fast though, I never wait for anything.
I suppose it's Apple Silicon? Because that would still be in line with Intel-based macs becoming less performant over time
I'd guess not the latter — anecdotally, my intel mac has been increasingly sluggish after each macos upgrade, even after a clean install. I finally decided to revert to the oldest macos version possible (and then update by just one major version since unfortunately some apps I need don't support Catalina anymore) and the difference is night and day — my memory was right and my laptop _was_ faster before. And it's not hardware getting old or battery problems, it's the OS.
So I don't know if older macs are intentionally crippled or they're just ignored during QA, but I don't believe they're actually intentionally supported
It does remove songs, or at the very least disables some (you can toggle a setting to see disabled songs) presumably due to copyright/licensing issues. But worse, it sometimes _replaces_ a song with a different version, with no warning and no recourse
I'm not saying _nobody_ uses those devices, I'm just saying they're sufficiently old that saying _my app supports Android 3.x_ is moot, because the usage on that API will be near 0 anyway, so you never really know if you _support_ that version outside of any testing that you might be doing. Android 4 and lower have estimated share of 0.3%-0.7% depending on a source ([1], [2]). Of course HN users will be more likely to have those devices too. And then of 0.5% users that maybe will install the app some will have no issues, some will have issues but not notice, some will notice but not bother reporting.
> curious how one ensures compatibility with ancient versions; actual testing, a compatibility linter, other?
Android linter does check that access to APIs added in newer versions is gated behind a version check, for example. But frankly I feel like compatibility with any Android version less than 4 (or even 5) is in practice a non-issue, simply because there are no users with such ancient Android. And the few that would use such devices are so far and between that any issues don't surface
It's not difficult to write sub-10Mb release APK for a production app with lots of features while using all the compat libraries and other useful dependencies (that do make life a lot easier). Our app is ~7Mb, and we don't even heavily optimize for APK size.
IME biggest dependencies are not compat libraries or _typical_ dependencies that Android apps need (like image loaders), but anything that involves native code. Media capabilities is one thing, but also solutions for analytics/user monitoring/SDKs for integration with Important Companies are more often than not _massive_, and companies like to track the user from many angles ¯\_(ツ)_/¯
> A single tool to replace pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, and more.