Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
carderne
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
13 ms
·
61.
▲
by
carderne
2y ago
Good point, but that's not always desirable. If you have strict type-checking and _aren't_ doing ser/de, it's likely not necessary (eg Rust doesn't do runtime checks).
62.
▲
by
carderne
2y ago
I think it would be useful to differentiate more clearly between what is offered by Python's type system, and what is offered by Pydantic. That is, you can approximate Rusts's enum (sum type) with pure Python using whatever combin
63.
▲
by
carderne
2y ago
I know it’s a good thing. I’m just curious to what degree packagers see this as extra work. Seems like probably not.
64.
▲
by
carderne
2y ago
Does this make the downstream packagers’ jobs harder — they must now presumably have Perl, Bison, Flex and DocBook installed on the packaging machines?
65.
▲
by
carderne
2y ago
What about rqlite?
66.
▲
by
carderne
2y ago
HN stripped the "Why" from the title. Just added it back. To answer your question, tldr: config not declarative enough, reliability issues, permissions not granular enough, networking/peering has gaps. But it's all prett
67.
▲
Why we left Fly.io
(rdrn.me)
7 points
by
carderne
2y ago
|
3 comments
68.
▲
The Vast Emptiness of Social Psychology
(cremieux.xyz)
8 points
by
carderne
2y ago
|
3 comments
69.
▲
by
carderne
2y ago
The Inner JSON Effect. Most recent HN discussion of it: https://news.ycombinator.com/item?id=40923258
70.
▲
by
carderne
2y ago
Really appreciate your saying that. I don’t have any tracking stuff, so nice to hear occasionally that someone read + enjoyed something!
71.
▲
by
carderne
2y ago
Interesting. Not sure I understand the bit about Python/Node: you’re still getting Node, just wrapped in a Python package, unless I misunderstood something. My main gripe with pyright is I wish the console output was prettier and less
72.
▲
by
carderne
2y ago
Enjoyed the post, thanks. One question: why don’t you use restic+rclone on macOS? They both support it and I’d assume you could simplify your system a bit…
73.
▲
Beyond Hypermodern: Python is easy now
(rdrn.me)
18 points
by
carderne
2y ago
|
5 comments
74.
▲
by
carderne
2y ago
But 0 in Central Park, apparently.
75.
▲
FlatGeobuf – every census block in the USA
(flatgeobuf.org)
2 points
by
carderne
2y ago
|
3 comments
76.
▲
by
carderne
2y ago
Realised FlatGeobuf [0] (no connection except a tiny PR once) has never been posted as a link before. FlatGeobuf is perfect for things like the car crash map that was posted a few days ago [1]. [0] https://github.com/flatgeo
77.
▲
by
carderne
2y ago
Totally agree, not at all obvious what’s gonna happen once you paste something.
78.
▲
by
carderne
2y ago
Find this pretty useful for understanding query plans. There are some sample plans on their website: https://explain.dalibo.com/
79.
▲
by
carderne
2y ago
You’ve had some other recommendations already but I’d suggest also looking into FlatGeobuf [0] for this use case. Have a look at the MapLibre example with a 12GB example [1]. You don’t need a server at all (unlike MBTiles) and will be able
80.
▲
PEV2: PostgreSQL Execution Plan Visualizer
(github.com)
21 points
by
carderne
2y ago
|
5 comments
81.
▲
by
carderne
2y ago
Oh yeah that looks ideal. My initial idea was down those lines, but realised this wouldn't be possible with many (most?) languages/ORMs/adapters. Eg for Prisma (TypeScript ORM) it would need to be built in to Prisma itself. A
82.
▲
by
carderne
2y ago
Oh thanks for sharing, never found that somehow. It seems that's mostly formalising the general idea of adding a prefix to a UUID, but you still end up storing them as variable length strings. I left 4 bits out in UPID as a version spe
83.
▲
by
carderne
2y ago
Thanks for the comment! Yeah I really love Stripe IDs and if I was building an API-first product would definitely make that a priority, but can imagine a bit of headache if there isn't global buy-in from day one... Would be great to he
84.
▲
by
carderne
2y ago
My understanding from Stripe was that they're stored with the prefix as text in the DB, but I might be wrong. As for doing the translation at the API boundary, my only gripe is that it's likely to be error-prone: every dev needs t
85.
▲
by
carderne
2y ago
Main reason would be that every dev must then remember to add/strip a prefix at some boundary around the DB, which I think would be pretty error prone. A more minor benefit maybe is that they're natively presented with the prefix
86.
▲
by
carderne
2y ago
Last time this discussion came up, someone shared this nice article[0] about all the different ID options. It mentions Stripe IDs, which have pretty prefixes like "prod_foo" and "user_bar". These are great for users of t
87.
▲
by
carderne
3y ago
Yeah I imagine it depends where the data is coming from and what exactly it looks like (num fields, dtypes...?). What I did was source data -> Numpy Structured Array [0] -> Postgres binary [1]. Bit of a pain getting it into the requir
88.
▲
by
carderne
3y ago
Hey OP (assuming you're the author), you might be interested in this similar experiment I did about four years ago, same dataset, same target, similar goal! https://rdrn.me/optimising-sql/ Similar sequence of inve
89.
▲
by
carderne
3y ago
Same exact experience, a year on Fly but moved to GCP (GKE in our case for reasons) a month or two ago. Super slick when it worked, but that wasn’t often enough…
90.
▲
by
carderne
3y ago
Awesome, thanks for responding. Very keen to give Tauri a spin, seems like a happy middle way between native toolkits (which I'm just never going to spend the time to learn properly) and Electron (which I'm just never going to lov
More ›