- That's a lot of code for a PR, though i should admit I have made PR's being half that size myself.
Personally I think it's difficult to address these kinds of PR's but I also think that git is terrible at providing solutions to this problem.
The concept of stacked PR's are fine up to the point where you need to make changes throughout all yours branches, then it becomes a mess. If you (like me) might have a tendency to rewrite your solution several times before ending up with the final result, then having to split this into several PR's does not help anyone. The first PR will likely be outdated the moment I begin working on the next.
Open source is also more difficult in this case because contrary to working for a company with a schedule, deadlines etc... you can't (well you shouldn't) rush a review when it's on your own time. As such PR's can sit for weeks or months without being addressed. When you eventually need to reply to comments about how, why etc.. you have forgotten most of it and needs to read the code yourself to re-claim the reasoning. At that time it might be easier to re-read a 9000 lines PR over time rather than reading 5-10 PR's with maybe meaningful descriptions and outcome where the implementation changes every time.
Also, if it's from a new contributor, I wouldn't accept such a PR, vibe coded or not.
- Odin has no primary use case, it just happens that a lot of the members in the community have made or are interested in game making
- I got the iPhone 13 mini as a work phone for the sole reason of it being the smallest iPhone at the time. I too dislike the phone landscape nowadays with their ridiculous and ever increasing sizes.
My personal device is a Motorola Razr 50 Ultra, which I got because while it's huge when flipped, it's portable enough when it's closed. I can have it in my pocket without it falling out.. without it being annoying while i put on shoes etc...
I use its cover screen a fair amount too, to avoid having to flip it open, which is also why I got the ultra rather than the slightly smaller version.
- It's been years since I used Total Commander, so I don't recall all its features anymore. On macOS I use Marta https://marta.sh/.
- It's not my hill to die on but I will say use wireless in-ear monitors myself to avoid ever having to deal with adapters because... Adapters are terrible, often wonky in one way or another, incredibly inconvenient for anything but having them lie on a desk. It's also something you easily forget to carry around, or you lose or break because of shoddy build quality.
It's a bad alternative to something that wasn't a problem except it took up space and people still talk about it because there's still a need for something better
- Yes, as mentioned here on the overview: https://odin-lang.org/docs/overview/#built-in-constants-valu...
x: int // initialized with its zero value
y: int = --- // uses uninitialized memory
- Not loving this trend that we are starting to doubt whether everything is AI generated.
Ahoy is a known Youtuber who has made content for 14 years. His voice is definitely not AI generated.
- "Study smarter" or just make it easier to cheat... you be the judge of that. Maybe we should just go back to doing tests and exams on paper? What was the benefit of going digital with this again?
- > a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready.
A blind person can and should get cues from their assistive technologies that an item is is being loaded and is shown, either using announcements or aria tags that provide this information to the user.
While its fine to expect that something is available immediately, that's rarely a realistic expectation, whether you're blind or not.
- The _mostly_ same behavior is what caused the problem though :P I'm curious, did these solutions come to pass because you had to make adjustments based on actual user feedback or was it just a developer trying to think ahead? I'm questioning whether forcing the user to tab to get to the menu item is a hindrance at all or whether the animation was a problem.
Maybe the former could have been solved using ARIA tags or maybe it would require bigger changes to the component itself. Accessibility is a roller-coaster for all these reasons alone.
- Of course there are edge cases, I work with accessibility too, for an app in the public sector where WCAG rules are no joke, so I know this as well but even so, we don't build custom accessibility UI for our users. We (try to) build the UI with accessibility in mind so it's scalable, can be used and navigate properly by voice over and keyboard.
On mobile it's not perfect either but in general you do have features to change stuff like. focus, grouping of elements, how the keyboard navigate the view stack, how to access a button through custom actions and like you mention, change the tab index programmatically.
Even so, not everything can be fixed or handled through standard accessibility means and as such hacks will inevitably make it into the products.
I get what you're saying but I still think that making things accessible and designing with common accessibility in mind should be default and as such it has to be thought about when designing and developing from the get go. Having to create custom interfaces to fulfill a specific need might be a good fit for some things but not when developing apps and websites unless you're targeting that user-group specifically.
- Seems like a non bug to me.
The first mistake the developer made, was that he wanted to create a different user experience between keyboard and mouse. Stick to what you get by default and design your components so they work for both usecases. Don't try to be smart when it comes to accessibility.
What he ended up doing is what I would have considered a hack. A solution that inevitably breaks or has side effects.
The reason there rarely are good handles to do things differently in accessibility context, is because it's not something that's meant to be handled differently.
- While I understand your question is about the Transit app in general, I'd just like to mention in correlation to the article that my team and I worked with one of the public transport operators in Denmark, to utilize the motion predictability feature found in Android and iOS SDK's, so I can enlighten you with some details regarding that.
Our conclusion was that the feature didn't work in the danish metros for reasons we never got to deep dive into. It's most likely related to the fact that many of the metro stations are built in concrete, as such there's no GPS data in most of them unless you're very close to or on the surface and no motion data.
I'd be surprised if they got this particular feature working but who knows... maybe if we had looked into the raw sensor output we might have been able to work something out.
In the end we made a solution to help determine when you're moving or not by utilizing beacons.
- While Lottie has existed for a long time, I'd consider looking into Rive instead https://rive.app/
Compared to Lottie, you can make animations for Rive directly in their web editor.
The downside is that you have to create an account to use it.
- The whole concurrency agenda with local reasoning sounds great in theory but in practice becomes such a pain in the ass for projects that has existed for years.
Maybe our current app has unknown data race bugs, maybe not... with a crash free session percentage of 99.80% and hundreds of thousand monthly users, it's not something I consider a big enough problem, to the point where more friction to the language should be added to maybe fix it.
- Yup I agree, to me it is turning into the next c++ with the kitchen sink in terms of features. The language is trying too hard to cater to too many use cases.
At some point I hope it stabilizes without it being the end of the language.
I use Swift every day and while I still enjoy it, I think the language was nicer to use in its earlier iterations than it is now, which is a shame.
- The native experience benefits the user and the device more because it's using the APIs as they were intended, WPA's will forever be the inferior choice.
- Imo there's nothing suspicious about, I am an early adopter and I happily pay for it. It simply provides better results than Google, Bing, DDG and any other search engine I've tried. I'm not a fan of subscription based software/services at all, but for once I think it makes sense when it comes to search queries.
Before I was an avid user of google but seeing the results getting worse and worse made me look for different solutions. For now i'm interested in supporting a search engine that can keep itself above water through my wallet.
- I'd say like with most things, simply going through the material is not enough. You need to follow the tips like reading the script out loud. This has had major impact on my ability to learn and furthermore speak the language.
I've been using Duolingo daily for soon 3 years (pro user), approx. 30 min, learning Japanese. Although I also use other apps for deeper knowledge and understanding of the grammar, I would be lying if I said duo didn't work for me. I understand most of what I've learned so far although reading is still a challenge, especially text with more complex kanji in it.
You say you've gone through the course but is that still true? at least today there are 810 quests, each with a meter for you to fill up.
Id be shocked if you got through all that and still didn't know how to count to ten.
Duolingo is no silver bullet. You still need to be really interested in learning, practice as much as possible and last but not least, investigate and deep dive into the grammar.
In case you're interested, here are the other apps I use for learning Japanese. - KanjiGarden, for memorizing kanji - Takoboto, my favorite dictionary - Renshuu, good for deeper explanation of grammar
It's the niche that wants open and flexible devices and the ability to customize everything.
Let's not ruin iOS by trying to make it Android.
I say that both as an iOS developer and Android user.