The Swiss Food Composition Database (https://naehrwertdaten.ch/en/) is an exceptional resource for detailed nutritional information on over 1,100 foods available in Switzerland but also around the world. It offers comprehensive data on macronutrients, micronutrients, and fat composition.
Maybe that would be a good source to challenge and validate the values provided by your LLM approach.
Thank you for your feedback. This would be a great dataset to include -- my next priority is the Japanese government dataset which would expand food coverage for more traditional Asian diets, but this is a great resource.
As a developer of local applications, I take issue with the notion that apps should be free simply because they don't incur server costs. This argument overlooks several crucial aspects of software development:
Development costs: The bulk of an app's expense lies in its continuous development, not in hosting. Even if backend services can be run for a nominal fee, the time and expertise required for ongoing maintenance, updates, and improvements are significant.
Value proposition: Apps provide utility and solve problems for users. The price should reflect this value, not just the operational costs.
Sustainability: Charging for apps ensures developers can continue to support and improve their products, benefiting users in the long run.
Hidden costs: While server costs might be minimal, there are other expenses like development tools, testing devices, and occasional third-party services that add up.
It's a notetaking app pal, it's not that serious. And certainly not worthy of a subscription model. Kind of ridiculous that they're using this platform as free advertising for what is effectively one of those cashgrab apps.
Amazing project. Would consider buying one, if you sent to Germany.
Did you consider writing your app using the Web Serial API? If you did, why did you decide to go the native route?
> Did you consider writing your app using the Web Serial API? If you did, why did you decide to go the native route?
I went the native route mainly because I love native software, particularly native Mac software. I never quite enjoy using web apps, but I certainly understand the appeal.
Until I get the ordering system taking international addresses, send me an email ([email protected]) with your address and I can send a Stripe invoice.
It appears that the problem is related to the version string transmitted by Firefox Mobile. If they were to send an older user agent string, the issue would likely be resolved. However, any rollback would need to be implemented by Firefox, and it seems they are not at fault here.
From Google's standpoint, this issue may be considered a "new" bug, which means they need to conduct an investigation and address it. Consequently, a rollback is not a viable solution for them.
Why would Firefox have to "rollback" their UA string back to version 64, released 6 years ago (2018)? That seems utterly ridiculous for a server side UA sniffing bug rolled out by the Google Search Team.
Depends on what you consider minimal, but I enjoy working with PocketBase and VanJS[1]. However there is no component library built in (if this is what you were asking for).
Amazing. I was looking for something like this about a year ago. Looks very promising and may be a good drop in replacement for some simple Auth0 use-cases as well as homelab setups.
I was not able to get past „ redirect_uri must be on the same domain as client_id“. Maybe you can give an example of a valid client id for your demo instance.
Sorry, this is indeed not very clear. Others already answered well, but if you look at the example[0] config you can see how you would use your own instance of obligator as a client to the instance running at lastlogin.io. This is a bit meta, but applies equally to any client application.
I recently enjoyed reading https://every-layout.dev. Even though I considered myself to be quite good at CSS, some of the ideas covered in that book (like thinking about how big your elements should be and let the browser handle the breaking instead of relying on media queries) was eye opening for me.
