Lots of non Americans support the change too. Master was a terrible default name, switching it to a better name that’s also more inclusive language was a good idea. Where American politics infected things was the the reactionary response of people who are vehemently opposed to any attempt to fix problems that don’t directly effect them.
This whole 'master branch' outrage doesn't even make sense. Should saying things like:
"I've mastered computer programming." also be an offense?
We absolutely should deny and disregard these nonsensical demands _by principle_. What was even the actual case made by people who wanted this? And don't tell me "well it's not a big deal, just accept it don't whine about something so small", because that won't fly, or shouldn't at least.
You can go read the justification in a million places, I’m not going to repeat it badly here.
From your tone I see you’d like to have an argument. While I’m sure that will make you feel good about yourself on this dull Monday morning, I doubt it will result in much valuable interchange of perspective.
I suppose the justification was not heavy enough. Master's degrees, master bedrooms, mastering a skill, and calling someone a master of their craft, in fact, still exist, and nobody seems to complain about thouse funnily enough. Just admit that this just bs.
My problem with YAML is that even when you try to keep it simple it tries its best to trip you up with some obscure feature you never wanted to deal with
This is the place where the date picker does not help the user at all. It's easier to type the, presumably memorized, date, than to look it up in the calendar no matter how nice and handy the calendar is. Sure it does solve validation problem. Or maybe not correctly, don't ask about locales and date adjustments.
Even if, that does not help. When asked for a birthday I need validation of the date in country when I was born, not the country I'm in, not the locale I'm using for display and not the locale server/requesting company is in.
Obviously, but additionally, providing validation on the frontend can help UX a lot.
Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission.
And one solution for that problem can be using a native picker.
I do understand what "client-side" validation is, but I wish it had a different name, because people think they can just validate client-side and they do not bother doing it on the server... for some reason, I do not know. It should be obvious though, right? Yet it is not.
I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for <input type="date">. Their purpose is to enter a date. That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlighting it as a pet peeve won't make it happen at scale. What do you suggest instead?
The answer shouldn't be "create something custom for entering dates that don't happen to be in the current year", it should be "fix the datepicker so it's fit for purpose".
I am so glad that so many people in this thread confirm how bad the native date pickers are; i thought I was alone.
Just picking the year is so difficult already on both Android and iOS as well as desktop Chrome, so a custom widget is immediately 100x better.
Yes, in theory it would be best to display the native picker because in theory it has a great UX, but in practice the native browsers' implementations are mostly just really, really bad, for whatever reason.
That's what I really dislike about the linked article - it doesn't even check the native implementations for their quality but just argues as if they are great.
Ideally there would be an input type for this, month comes close to the correct UI on iOS but has lots of problems. I don’t think the calendar picker style will ever work well for entering birthdays and such, so yeah the answer is build your own thing or use a library.
Lines in the air don’t need any additional insulation. Cables underground need to be insulated. Now imagine how much insulation you need from 400kv, multiplied by hundreds of miles of cable and imagine how expensive that is. Now consider what happens if there’s a fault.
I’m fairly sure that farmers often buy seeds rather than harvesting them. There are lots of reasons for this but essentially growing seeds and growing produce is just quite different. I don’t think it’s the dramatic shift you’re making it out to be.
My grandfather in the US Midwest in the 1950s farmed specifically to harvest seeds for planting which he then sold to his regional neighbors via distributors. I don't know the specifics, but I understand that even back then the farming practices were sufficiently different that the specialization was warranted.
It depends on the crop. With cereals, the seed is the product, and you could divert a part of production to next year's planting. With other crops, harvest may happen before seeds mature and may require special processing to extract them for the seed producers.
If you are planting hybrid seeds you would never save seeds because their children don't yield well. Hybrid yields so much better that it isn't worth planting anything else if you have the option.
>With cereals, the seed is the product, and you could divert a part of production to next year's planting.
Theoretically, but generally that doesn't happen because you want hybrid seeds that need to be grown every year to get the traits you want, you don't want to plant the seeds you harvested from the hybrid plants.
reply