BankID is _in theory_ a nice technology. However, it is only handed out to people registered with the Swedish tax authorities holding a Swedish bank account.

All daily activities are nowadays bound to BankID: need a doctor's appointment? -> needs BankID; Want to buy something on Blocket? -> needs BankID.

As an European frequently spending some time in Sweden not in possession of a Swedish tax #, I feel very much excluded from online and partially offline activities in this country.

Comments URL: https://news.ycombinator.com/item?id=47893516

Points: 95

# Comments: 12

A few other interesting tasks I was involved back then were:

- smashing an oven's door until the hinges would give up - testing new heating elements in the open (basically, building a gigantic grill) - appliance transport packaging tests - cooking and baking on a daily basis to make sure food turns out as expected

Overall, home appliances are a great product as an engineer to work on. It is a product you usually use multiple times a day. And if you love cooking yourself, even better :-)

When using v7, I need some sort of audit that checks in every API contract for the usage of v7 and potential information leakage.

Detecting V7 uuids in the API contract would probably require me to enforce a special key name (uuidv7 & uuid for v4) for easier audit.

Engineers will get this wrong more than once - especially in a mixed team of Jr/sr.

Also, the API contracts will look a bit inconsistent: some resources will get addressed by v7, others by v4. On top, by using v4 on certain resources, I'd leak the information that those resources addressed by v4 will contain sensitive information.

By sticking to v4, I'd have the same identifier for all resources across the API. When needed, I can expose the creation timestamp in the response separately. Audit is much simpler since the fields state explicitly what they will contain.

Comments URL: https://news.ycombinator.com/item?id=43440122

Points: 3

# Comments: 1

My current setup:

- generate a new psql testcontainer _or_ reuse an existing one by using a fixed name for the container - connect to the psql container with no database selected - create a new database using a random database name - connect to the randomly generated database - initialize the project's tables - run a test - drop the database - keep the testcontainer up and running and reuse with next test

With this setup, most tests run sub-second;

What you would do in go is:

- either a new goroutine per message

- or installing a worker pool with a predefined goroutine size accepting messages for processing

In case you trigger a native fetch, you've got no way to cancel the call due to the missing cleanup fn.

When it comes to efficiency, internal gear hubs sadly aren't yet in the range of a rear derailleur.

https://fahrradzukunft.de/17/wirkungsgradmessungen-an-nabens...

A dirty rear derailleur of course also reduces the drive train's efficiency by a lot - which can be solved by cleaning the chain every other month.

When moving towards belt drives, you need a very stiff frame which can be opened/split in the back to fit the belt. These frames are more expensive to produce which will furthermore increase the overall bike's price.

Ideally, we all train our legs to be able to handle a single speed setup ;-)

The new beta docs just recently changed again removing old best practices concerning dependency arrays in useEffect hooks in favor of a new potential hook called useEffectEvent (which is still experimental).

I love to work with react. However, it takes _a lot of time_ onboarding new engineers for tasks which are a bit more complicated in nature. Also, using hooks the wrong way can really mess up your product big times.

It would be nice to see react moving in a direction which is by design/architecture less error-prone.

Looking at next.js for example. There are so many ways to fetch data for a page: getStaticProps, getInitialProps, getServerSideProps and the API handler (I hope I didn't miss any now). Each single one of those uses their own naming concepts (context vs req/res, query vs params). It is very easy - especially for newcomers to the frontend - to break things or leak data by not following the concepts of the frontend.

By dividing backend and frontend on a language level, you get a clear boundary on an API level which helps developers having a clear focus on their actual problem scope.

I guess you could solve the problem by having two node.js applications: one providing API endpoints and one taking care of the view. By then, I'd just switch to a properly type-safe language for the backend.

https://youtube.com/c/Slingshotchannel

The Incose handbook for systems engineering: https://www.incose.org/products-and-publications/se-handbook

(You might be able to find an older version for free)

Disclaimer: I've been participating in a Systems Engineering master program @ university a while back which was based on both Haberfellner (and is finally available in English also) and Incose.

My ideal combination to cover about 80-90% of power needs whilst camping/hiking/cycling would be a combination of water turbine (for rivers or tiny streams) and solar.

In case I'd be hiking in an area with no water supply, I'd consider something like a wind turbine. Yet, I wouldn't know why I would want to hike in an area with no water supply ;-)

Due to limited time (fruits was built within a few days), we reduced the product to the most simple MVP we could come up with. We will now be adding features on a daily basis :-)