kashug

Often when I use number-input it's because I want numerical keyboard when people interact with it on a smartphone.

Yes, input type="number" is not the best, but when I ask for 2FA codes or credit card number a metric keyboard makes sense. And this is currently the best way I know to achieve it.

But zoning is also part of the issue. Residental areas many places in NA is often strictly residental - designed around that people can just take the car to go grocery shopping.

In europe it is more common that you have things like a supermarket in walkable distance (or atleast short trip on a bike).

I think this is the same with every sport, in my experience, Seen in with swimmers cycelists. But also if you go cross country skiing during the winter here in Norway you meet the same kind of people.

This feature is currently not supported my microsoft teams. And I guess a lot of corporations use teams for meetings.

My problem with it is that once you have total surveillance it is hard to get rid of. And even if I trust the current goverment, do I trust the next?

> You don't actually want these changes to end up in the main branch before they are done

I see no problem with that if it is a small change that can de deployed safely. (for instance hidden behind a feature-toggle where applicable).

We tend to strive for small, short lived branches. We usually don't want PRs with more than a couple of days work - to keep them small, easy to test. It also makes the amount of changes going to production at any time small.

The best would be if any specific feature is small enough to only be a few days work. But out experience is that it is not allways easy to do that - and sometimes some features will take weeks before they are done.

I agree that code review is not QA. But I read it as the writer of the post comes from a team where they do QA on pull-requests. And QA is assumed to be done on a per PR basis. But here I think different teams will have different approaches and pipelines.

On my current team, we want most tests to be automatic. But the manual regression testing that might be needed is mostly done by other developers. A separate test-environment is created for each PR, and the link posted in the pull-request. So when looking at a pull-quest we expect people to do both a code-review and QA.

In my team approving a PR means you approve for the code to go to production. So you need to consider both code quality and whatever QA is needed. But thats just our way t do it - other teams do things differently. And I think thats OK, there is no silver bullet.

I often see people speak about requiring users to have JS enabled as a problem. But is that really an issue? I remember 5-10 years ago I would use things like no-script to disable javascript, and only enable on specific sites. But with the way modern frontends are, I would expect most website to not work at all if I disabled JS. So I would expect most users to have JS enabled anyway.

I can't remember the last time I created a website in a professional setting that would work without JS. Everything is written in things like React, Angular and Vue.js these days. And that seems to be the case for most modern websites. Atleast things made here in Oslo.

But the search is not as good. Or good might be subjective in this case. But I tried using DDG mutliple times, but every time I end up just doing the same search on google becouse it is much better at giving me the result I want.

But this is just my personal experience.

Vulkan-support is one of the main features on Godot 4.0 which is still not in alpha. But from what I've gathered alpha-release is pretty close. But no date announced.

very much relies on where you live. For instance if you live near the coast in southern parts of Norway and go for a hike you should allways check for ticks afterwards. I usually just take a shower as soon as I get back home to make sure i get them off before they bite.

It is not uncommon to find multiple ticks on your clothes if you have been walking in tall grass. But they usually take quite a while before they find a spot to bite. So if you take some precautions it is not a big problem.

Patents are a pertect example of something that did make sense back when they were made. It was a trade off for having people share new knowledge which would benefit society as a whole. But as a price they got "monopoly" on using it for a while after sharing the patent.

But like many other things, it has been exploited, especially by big corporations. And the patents no longer work as intended. And the big problem is that theres so much money on the line that is it not easy to change. I would assume large corporations already spend absurd amounts of money on lobbying for the patent-rules to work in their favor.

Patents as a concept I am all for. It is a good way to make sure that new entrepreneurs can make it to market before "big-corp" steals their idea and just push them out. But they would have to change how they work to stop patent-sharks and the big exploitations by said big-corp.

we tried semantic versioning for some time, but gave up. It is still people writing the code - and people do mistakes. So even when something is released as a patch how do we know that it was a mistake and it should have been a minor or a major version. Or they introduced a bug that would break our system?

So in the end we would still end up not trusting it and rely on testing (hopefully as automatic as possible) before we could merge the upgrade.

In the end we just switched to using timestamp-based version numbers and just try to upgrade often enough so each incremental change is small. And try to have good automatic tests that can do most of the regression testing for us.