5
points
newswangerd
Joined 84 karma
- newswangerdI’m curious about this too. I’d worry about a local burglar having this information, but what can a Chinese tech company do with this data that I should be concerned about?
- I was counting the ESTA. I don’t have any experience with it, so you’ll have to pardon my ignorance.
- Canada, Marshall Islands, Micronesia and Palau. A very weird assortment of countries, aside from Canada.
https://www.passportindex.org/comparebyDestination.php?p1=us...
- I’ve always argued that the US is the most powerful passport despite not granting access to the most countries for one simple reason: it’s one of only half a dozen passports that lets you visit the US visa free.
- I'm so impressed by how quickly this team can ship new features. It seems like every few weeks there's a new major update!
- The funny thing is that I would be totally willing to pay for a license if in exchange for no ads and no needing a Microsoft account.
- Huh, I submitted this article last week when it came out and it didn’t get any attention at all.
This demo is super cool! I’ve been dreaming about a game with an engine like this for the last 5 years. Super happy to see people experimenting with it!
- Would it be possible to do both on a single panel? In other words, put photovoltaic cells on the sunny side and thermoelectric generators on the shady side.
- 2 points
- This is very cool! I'm going to take a look at your code.
I've been playing with the idea of creating a "protobuf db" library that would allow you define schemas in protobuf and then query them with something akin to an ORM. It wouldn't make any sense for large databases, but for embedded applications that only need to store a few MB of data, it would be perfect.
- I've never heard of ConnectRPC before! Will check it out.
- Yeah! I'm using a gRPC daemon on PC and go mobile bindings on mobile.
- I guess a better term for it would be frontend and business logic. On iOS and Android the business logic (backend) is run using go mobile bindings and are imported directly into the native framework. For Windows, Mac and Linux, it runs as a gRPC daemon in the background. You could use C bindings for PC, but those seemed like a hassle, and I need a daemon anyway.
- I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function via the flutter FFI that takes in a binary array and then converts it to a protobuf object. This gives me a nice separation of concerns between my business logic and frontend while also providing easy to use objects for the front and backend.
Not sure that I'd recommend this approach to everyone. Protobuf code generation can be finicky to set up, but I'm doing it so that I can access go's rich array of libraries in my app.
- The best use case I've found for tiny models (<5bn params) as a reference tool for when I don't have WiFi. I've been using qwen on my MacBook Air as a replacement for Google while I'm writing code on flights. They work great for asking basic questions about syntax and documentation.
- This is why I love hacker news. I often find myself falling for this stuff and thinking "yeah, that makes a lot of sense". It's always good come back to the comments and get a good old fashioned reality check.
- It feels like the problem is that we've drastically improved people's lifespans, but not their healthspans. Back when these systems started getting implemented, you could reasonably work up to the retirement age without too many issues. Nowadays, people may be living to 80 instead of 60, but our ability to work and willingness to hire people past 60 hasn't gone up with the increase in lifespan.
- Does anyone have any idea what this looks like in practice? How do you put a tariff what essentially amounts to information?
- I've been developing in Django with Django Rest Framework for 10+ years and just recently built my first FastAPI project, so I may be a little bit biased here.
Django takes care of a lot of common functionality for you. The biggest things for me are:
- Authentication: this includes safely handling sessions, cookies, password hashes as well as integrations with SSO providers via libraries like Social Django.
- ORM: love it or hate it, the ORM just does everything. You mostly don't need to worry or think about migrations or database support.
- Admin panel: the builtin admin panel is a great way to get a quick UI that can, in some cases, handle a pretty big swath of the UI needs for your app.
With that said, there are some things that I LOVED about FastAPI. Using pydantic for serialization is way nicer than the serializers you get from Django Rest Framework. The DRF serializers just feel slow and antiquated after using pydantic. FastAPI is also much lighter weight, and works great if you just need a quick and dirty API server.
I think that my recommendation would be to use FastAPI for microservices and Django for anything that needs to handle more than a few REST API endpoints. All the extra functionality in Django is great if you want to build a production monolith, but all those extra features are unnecessary bloat for microservices.