HN user

kashug

138 karma
Posts0
Comments36
View on HN
No posts found.

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.

Buying an ebike 5 years ago

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).

On Code Review 5 years ago

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.

On Code Review 5 years ago

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.

If I create a library I would usually make it to solve my own usecase. And if you mainly work with react-apps, and your plan is to use it in an react app. Why not also make the library in react?

In this case, I guess the developer wanted to use JSX to create it. And you could ofc use JSX without React. But most people are used to using it in react-context, and plan to use it in an react-app anyway.

So to answer your question, in my eyes it would be. Why not? If the devs plan on using it in react-app anyway, it's not their job to make sure it supports everyone elses usecase.

It seems to be something wrong on desktop. When I inspect the DOM you can see that the location of where you can click is not at the actual text.

It is also something a lot of people keep saying, but I have never seen proper documentation for it. So at this point I just think it is people repeating rumors.

But it would be interesting to read a proper documentation of it.

I will admit that I don't have enough understanding about macro-economics to know how everything will be affected. But inflation on low-price housing does make sense, but I will admit I don't know enough about the field to understand to what degree. So at this point I just wanted to state the points I've heard other people make related to UBI. (basically that is also comes with increased taxes).

My own opinion is that I don't know the correct way to do economics in the future. But I do think that we at some point should think very different. I don't think the current system works out for most people in the future. And UBI looks more like a band-aid than an actual fix.

Many places where I have seen people wanting to introduce UBI, increased (flat percentage) tax is often also suggested. The percentage is then suggested to be set at a level so that:

- People at low average income will have more money (the UBI-increase will be higher than the tax-increase)

- Average income: You get as much as before.

- Higher income: you pay more in taxes than you get from UBI.

Basically it ends up being a way to move money from the ones with higher incomes to the ones with less. It will ofc still give some inflation as poor people have more funds for basic needs. But other people will have less - and the average person just as much as before. Limiting the effect of the inflation.

This, so much this. I have been working as a cunsultant at both large companies and the public sector. And they are often unproductive - and for the same reasons. Loads of middle management that needs to be included in every decision-making, but noone that dares to actually make a decision without first asking their managers.

In my eyes, the reason much of the public sector is unproductive is not because it is not motivated by profit. But rather that it is too similar to large companies with loads different management-levels.

I once worked in the public sector when they embraced real autonomous teams with leaders that could actually make decisions when the team needed it. It was just as efficient as the best agile teams I have worked at in the private sector.

I wonder if the value of linked-in depends on where you live. I live in Norway and when I had linked-in I kept getting contacted by recruiters for totally uninteresting jobs. Often in England or Ireland.

Isn't the most common way to block "illegal websites" just to block it on the DNS owned by the ISP? (which is the one you will automatically use unless you configure something else). And just making their domain point to some website saying the site is blocked. Afaik this will still work. And the normal workaround of just changing to a different DNS should work aswell.

Is sniffing of traffic common in other countries?

When I am writing plain JS I often end up having to write loads of tests to check that I don't to wrong things with types. Did I remember to consider null/undefined? What if I sent in something totally different?

With TS I don't need to spend as much time with these types of tests. I just let the compiler do it for it. If my function says in it's signature the argument can't be null I don't need to do null-checks.

yes, and no. Some sites use DNS to route traffic to different servers for different regions. For instance you could have you site hosted on 2 different data-centers. 1 in EU and 1 in US. And then make US-centric DNS route traffic for your site to the US-datacenter and he EU-centric-dns to EU-data-center.

In that way you kinda know which DNS they used.

I'd argue that Kotlin is still a "Upcomming programming languages" - and I think one of its reasons for success is how well integrated it is into the IDE. (especially if you use intelliJ)