My iPhones last at least 3-4 years.
812 karma · joined February 25, 2015
Edit
> A somewhat common way to delay imports is to move the imports into functions (inline imports), but this practice requires more work to implement and maintain, and can be subverted by a single inadvertent top-level import. Additionally, it obfuscates the full set of dependencies for a module. Analysis of the Python standard library shows that approximately 17% of all imports outside tests (nearly 3500 total imports across 730 files) are already placed inside functions or methods specifically to defer their execution. This demonstrates that developers are already manually implementing lazy imports in performance-sensitive code, but doing so requires scattering imports throughout the codebase and makes the full dependency graph harder to understand at a glance.
I think this is a really weak foundation for this language feature. We don't need it.
The credibility is ranking. The ranking is a function of engagement. The engagement is a function of human nature. Things delightful, shocking, or unusual usually strike that chord. Sprinkle capitalism into the mix and people become professionally delightful, shocking, or unusual.
I don't think the ranking algorithms are the problem here.
Kinda sped read the article so apologies if I missed it, but why does the author here feel so entitled to something that clearly the company feels unreasonable to continuously maintain? They're clearly a struggling business, it feels like this author has a personal vendetta against the company and would rather they go out of business than break a 14 year old promise made from an entirely different internet economy era.
> Jackson says he now lives in “exile” in Dover, where he goes to the socializes with friends and plays video games.
你好！我是GLM-4.5，由智谱AI开发的大语言模型。很高兴见到你！有什么我可以帮助你的问题或任务吗？
https://github.com/cgzirim/not-shazam/blob/888070f3434acbc0a...
They will keep doing this as long as it's profitable. They lure you in with a cheap printer and they're trying to make their money after the initial purchase.
These "Customer Support" reps, when functioning as QA, knew the product better than product or eng, exactly how you're describing. I did enjoy that model, but they also did not write tests for us. They primarily executed manual test plans, after deploys, in production. They did provide more value than creating noise, but the engineering team still was QA, at least from an automated test standpoint.
I can tell you, I definitely didn't get training for QA tasks, but here I am doing them anyways. It's just work that needs to be done.
I have only had QA teams that wrote "test plans" and executed them manually, and in rarer cases, via automated browser / device tests. I consider these types of tests to be valuable, but less so than "unit tests" or "integration tests".
With this model, I have found that the engineering team ends up being the QA team in practice, and then the actual QA team often only finds bugs that aren't really bugs, just creating noise and taking away more value than they provide.
I would love to learn about QA team models that work. Manual tests are great, but they only go so far in my experience.
I'm not trying to knock on QA folks, I'm just sharing my experience.