my first iPhone was the original SE (which was essentially iPhone 4 expanded to 16:9 screen) and I'd say it was the perfect size of a phone, the reason why I opted for a larger screen even though my hands are kinda small for a man is that website and application design has completely shifted towards those large screens and small screens are unusable (and for me this has been true since 2019 when I switched to a larger screen)
it is kinda annoying, but apparently the consensus of modern design includes both lots of useless horizontal margins (lots of them just for the sake of visible rounded corners) and lots of vertical space taken by ads (iPhone 17 is actually 19.5:9, not 16:9, so ads take less vertical space on such a screen)...
and after a few months of using a larger screen I learned how to use it with one hand so it is possible - I rest my phone on 4 fingers and use thumb to interact, I only use two hands when typing (well two thumbs, but whatever)... but I still agree that the bigger the phone the more I'm worried it will fall down from my hand when operating it with one hand... the Max versions of iPhone do seem too large for me...
I mean maybe I have ADHD idk i'm not diagnosed, I don't generally have issues understanding Claude's output (even though I do think it's unnecessarily verbose), but I think this one is a general good advice which Claude ignores for some reason, and is especially annoying during debugging sessions, where it asks for 3 outputs, I paste one for it to process while getting the others, and then it immediately forgets it wanted the 2 others, and starts cooking up some wrong conclusions...
commits are local, so they're okay to me, I draw the line at pushing them... I either want to check its work while it's working, or let it finish and then check it all at once -> if it splits it work into smaller commits its easier for me to review it before pushing than if it was just uncommitted hundreds (or thousands) of lines of code all across the codebase.
Often I find I want to correct the LLM; I think it makes more sense to do that before the commit. I don't want to commit a bunch of half-baked work even if it is just local.
I never want Claude or any AI to post messages as myself..., if I'd wanted Claude to send a message to Slack, I'd want him to identify as Claude, or use some bot token, where it's clearly visible I'm not the one posting it (while I can still instruct Claude to say that the message was prompted by me).
Honestly, the worst thing about App Store rating system is that the ratings and reviews users see are country specific. So if you are in a small country and you try to use an app that is not really popular in your country, you see very few reviews, even if the app has thousands of reviews on the USA App Store.
Apps can only show you the Apple's dialog for rating three times a year. Many apps first show you their own popup/dialog asking stuff like "Do you like this app?" and only if you click "yes" there then they show you Apple's dialog. And they can show you their own dialog as many times as they like...
Yea, this dark pattern should be disallowed. Apps also do this before they request permissions (like for location and so on). First, they pop up their own dialog to "pre-flight" the request to use location. If the user says NO, they don't even ask using the official API. Only if the user says YES to the custom dialog do they shoot their shot with the official API. Super annoying.
Apps informing the user they are doing to ask for permission is not a dark pattern. It’s used to give user more context. Maybe you’ve seen it done poorly but when done correctly it’s good.
Why would you ever need that? I’m pretty sure you can already supply a custom explanation in the system permission modal to explain why you want the permission.
Because the native request prompt contains a very short string. You may use a permission for a number of things and need more description length to explain it. See the Apple HIG for an example:
I wonder if apple tracks metrics on apps that request permissions via iOS APIs and get turned down by the user. If they do, and use those metrics to flag or blacklist apps, that would suck: there are plenty of perfectly reasonable apps that I test out, see that they want permissions I don't want to give them, and then uninstall--no harm, no foul, just not for me.
So much this. When coding I use my LLM to hone the code to perfection before sending it to review, including running AI reviews on it multiple times and fixing obvious bugs so that reviewers have less work to do. I also test all my code manually (LLM can be helpful by giving me a list of test scenarios to consider). When reviewing PRs I carefully read the AI reviewer output, consider which points are relevant, which are irrelevant and only post the relevant issues when requesting changes.
I have coworkers who routinely post PRs with comments stating "all tests green, ready to review" and then I actually start the application, test it manually and it doesn't work. And don't get me started on reviewers who post the raw AI output of their "reviewing skill" and then I have to read through 30 paragraphs of "findings" most of which are irrelevant (just today I got the "valuable" feedback of "View is @api_view(["POST"]); no test asserts GET/PUT/PATCH/DELETE → 405")...
reply