donjoe

It's great you do have a bank-bound system in Finland. I hope their implementation is not as bad as e.g. the Swedish BankID.

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.

The video brought me back to my internship in the early 2010s. My job was testing the new US ovens (which for us Europeans are massive). The bus was amazing. Integrated into a LabView setup, you could basically collect any readings from the oven as well as remotely control it. Also, it was super easy to confirm "manual" actions (e.g. soleniods pushing buttons/motors turning knobs).

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

To me, the most important question is: how do I scale v7 in an environment of 20+ engineers?

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.

... If you live close by Theresienwiese, the city provides free cleaning for any accidents during Oktoberfest in your front/backyard also. I have to smile everytime I do find the note containing an emergency accident cleanup number in my mailbox :-)

Let's hope it's deepseek-compatible.

testcontainers is great. I struggled a bit with testcontainers due to the nature of one container per test which just felt too slow for writing gray/blackbox tests. The startup time for postgres was > 10 seconds. After a bit of experimenting, I am now quite happy with my configuration which allows me to have a snappy, almost instant testing experience.

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;

Which is perfectly fine. However, you will be able to process only a single message per connection at once.

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

UseMemo should not be used for fetching/kicking off a fetch either. UseMemo fans should be pure. Using logic that belongs into useEffect (logic that happens _outside_ the reactive flow) could potentially lead to other side effects which are very hard to debug. Just a example: a lot of fetch implementations are using fetch with a cache triggered in useMemo returning immediately. You will probably have a setState somewhere in the flow which will terribly interrupt react and break your page.

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

Bikes are all about efficiency since you don't use any energy but your own. Things change a bit nowadays with e-bikes.

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

Discussed here: https://news.ycombinator.com/item?id=34986267

... besides the change towards hooks and the react dev team which does not seem to be clear about how to best use them.

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.

Umidigi is another company to mention. Their Bison models pretty much fill the gap between a massive rugged phone and a standard phone. The phone's battery @~6kmAh usually covers a 2-3 day trip without charging.

To me, the biggest problem with javascript as a backend language is - especially in large teams: people tend to mix backend code with frontend code after a while.

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.

The knife throwing machine reminds me a lot of the slingshot channel:

https://youtube.com/c/Slingshotchannel

I recommend Haberfellner - Systems Engineering (ISBN 303013430X).

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.

Also, most portable devices on the market won't provide you with enough power for charging electronic devices in cloudy conditions.

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

Point taken. Thanks - will look into it!

... bank transfers is one of the feature requests already in our pipeline!

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

Hi, dev here, thanks for the input!

Fruits is a pivot for fanbase.com which sadly didn't make it. Within a few days, we managed to build fruits and launched it as the quickest MVP we could come up with. That's what you're seeing today. The imprint still points towards the current legal entity (fanbase GmbH). A new legal entity is currently under registration by the founders. Once the paperwork is done, the founders will move all assets to the new company and align the imprint accordingly.

Concerning taxation: this seems to be a clear improvement we need to work on communicating. Taxation is hard and we tried to break it down in a pricing calculator (which does not yet seem to do all that good of a job, point taken).

Disclaimer - as mentioned below/above in some of the comments: not the tax attorney ;-)

We are working with a tax office that helped us figuring out international taxation and will be able to answer all legal taxation questions in detail for each single country we're in business with.

Taxation for fruits essentially means:

- fruits charges the buyer and applies tax applicable for fruits (company in Germany) and the buyer in country XYZ

- each buyer will receive an invoice (issued by fruits)

- the seller will receive a single credit note for all sales performed within a month targeting a German company (fruits)

[Buyer] <<- Invoice (Tax) --- [fruits] <<- Credit note ->> [Seller]

disclaimer: developer, not tax attorney :-)

Our connected tax office figured out taxation concerning international transactions. Why and how different taxation rules apply depends on a couple of instruments and setups such as reverse tax charges, MOSS and others.

It basically burns down to fruits:

- charging the buyer with the applicable tax between fruits (company in Germany) and the buyer in country XYZ

- each buyer receiving an invoice (issued by fruits)

- the seller receiving a single credit note for all sales within that month targeting a German company (fruits)

We will have to clarify taxation as I can see from comments in this thread - thanks for your input!

This!

fruits will:

- charge the buyer with the applicable tax between fruits (company in Germany) and the buyer in Country XYZ

- each buyer will receive an invoice (issued by fruits)

- the seller will receive a single credit note for all sales within that month targeting a German company (fruits)

As I can see from the comments (above and below), we need to come up with a way explaining intl taxation more thoroughly.

Disclaimer: I am the developer and not the tax attourney. In case you do have any questions, feel free to contact us (or me) and we will set up a meeting with our Tax-Daniela which will be able to explain taxation-related tasks in detail with a proper legal background :-)

That's due to rules and regulations here in Germany. We need to have our outgoing and incoming invoices being handled properly to not run into tax fraud issues.

By talking to creators from e.g. OnlyFans, the biggest issues they faced was explaining their earnings to the tax authorities with no proper invoices at hand.

By further automating those tasks, we will be able to reduce costs dramatically and might get rid of the bookkeeping fee alltogether.

Thanks <3

Good catch, thanks!

Hi, one of the devs here - happy to answer any questions :-)

We're currently working exactly on that feature - been requested a few times yet. To keep the product as simple as possible for the MVP, we stripped all initial features and will add them step by step in the coming days.

I'd like to add a type of bike which is tiny but not foldable: a Minivelo.

I recently ordered a frame on AliExpress [0] equipped with internal cable routing and disc brake mounts, 2.25'' tire clearance. My build looks like a gravel bike. A gravel bike on 20'' with an 11 speed cassette, a drop bar and SRAM derailleur. Of course, not to miss a great carbon sear post. Including pedals and tires, the bike accounts for 10kg. In order to take it on flights, I did sew myself a backpack to fit the bike. Taking the bike apart takes me 10 minutes. It is a tiny bit too large for hand luggage but ideal for being checked in.

For me the frame is a great compromise between size, stiffness and maintainability.

Velo orange [1] does offer a lovely frameset, too. It's just hard to get by in Europe (at a reasonable price point).

[0] https://m.alibaba.com/product/1600169443757/SILVEROCK-Chrome...

[1] https://velo-orange.com/collections/neutrino-mini-velo

Look into velogical motors. Their tiny build size and removable battery should be a perfect fit.

http://www.velogical-engineering.com/velospeeder/produktinfo...

Even Germans don't know their insurance won't cover or just partially cover crashes happening > 130km/h (hint: Richtgeschwindigkeit/recommended speed is 130km/h everywhere, even on Autobahn stretches without speed limit).

[0] https://www.allianzdirect.de/kfz-versicherung/zahlt-die-vers...

I just see a huge parking lot. What do you see?

Why don't more people ask for better train connections?

Trains would allow kids, elderly, people without a driver's license or the financial means to afford a car to participate in society as well.