stephen

7 ms·

1.
by stephen 18d ago
> why not put the content from the md file in the code We do that :-) https://joist-orm.io/modeling/documentation/#two-way-syncing Technically the md file can have more free-form docs, but for the overview&#x2F
2.
by stephen 18d ago
I've also been a little-d DDD fan, and we've had luck with per-entity `md` files to language-independent document domain behavior/quirks/usages. I.e. an `Author.ts` has an `Author.md`, `Book.ts` has an `Book.md`. For age
3.
by stephen 22d ago
> trace optimizer/better sql in the next run Ah wow! I admittedly already linked this PR in another reply, but I'm trying similar things here: https://github.com/joist-orm/joist-orm/pull/1967 Nea
4.
by stephen 22d ago
> all you want is their name I have a WIP PR that addresses exactly this: https://github.com/joist-orm/joist-orm/pull/1967
5.
by stephen 22d ago
Afaict their solution is "here's a prolog-ish query DSL that safely translates FP-ish code to joins". That seems fine, but imo 1+Ns usually happen when you interleave business logic with database loads--like you have business
6.
by stephen 2mo ago
> tracking the table ... isn't reliable without [trigger] or [orm] We use sequences, which is neither of those, and has been very reliable for us. I included the disclaimer that you need a schema that follows strict sequence name =&
7.
by stephen 2mo ago
I haven't had time to try it, but I thought running PG on a copy-on-write filesystem with a specific "clone template" incantation would get you instant clones? Probably doable in a docker container? https://boring
8.
by stephen 2mo ago
We do similar, although lean into our strict "every table as a sequence" and "all FKs are deferred" conventions and only issue DELETEs for tables that actually were inserted by the test https://github.com&#x2F
9.
by stephen 2mo ago
I get why folks use tmux/herdr, but I already use i3wm/Hyprland for window/workspace management, and want to have "shared first class windows" instead of dual binds of "super-based binds for i3 windows ... oh w
10.
by stephen 2mo ago
Disclaimer I just edited this into my OP comment, but "generating boilerplate INSERTs" is not the main reason I use ORMs -- it's business rule enforcement. I.e. regardless of how easy it is to write `INSERT authors (...) VALU
11.
by stephen 2mo ago
You're right, that has been another "pro ORM" pitch that has gone awry and, taken to the extreme, is wrong imo. My nuanced articulation is "you don't have to write the _boilerplate_ SQL for the 90% of just-do-some-C
12.
by stephen 2mo ago
Fair point, both "pro ORM" and "anti ORM" camps are prone to extreme stances. I definitely don't agree with the "all queries must be executed through the ORM", and think that dogmatic stance has done a lot
13.
by stephen 2mo ago
I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==>
14.
by stephen 3mo ago
Right! That's why I think this is an exciting development. I assume everyone is downvoting me for "liking LLM slop", but really I just like the competition that "this is possible!" And would love a slop/non-slo
15.
by stephen 3mo ago
You're already using a new runtime with tsgo -- it's golang at build time -- but still running Node in prod, so the same could work here. :-) Agreed I would not want all Typescript users forced to use /this/ runtime, but
16.
by stephen 3mo ago
Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.
17.
by stephen 4mo ago
"beyond a junior level" -- I doubt this will change your mind, but this post is from the author of Tachyons, a "pre-Tailwinds" competitor that didn't get the same traction: https://mrmrs.cc/writing&#
18.
by stephen 7mo ago
Per "how to handle dynamic queries", it's admittedly pretty different b/c we're an ORM ( https://joist-orm.io/ ) that "fetches entities" instead of adhoc SQL queries, but our pattern for &qu
19.
by stephen 9mo ago
Hello! Yeah, I totally get Dagger is more "hey client please create a DAG via RPC calls", but just making something up in 30 seconds, like this is what I had in mind: https://gist.github.com/stephenh/8c7823229
20.
by stephen 9mo ago
Right, my point is that this: https://docs.dagger.io/cookbook/services?sdk=typescript Still looks like "a circa-2000s Java builder API" and doesn't look like pleasant / declarative / idiomatic
21.
by stephen 9mo ago
I thought Dagger had/has a lot of potential to be "AWS-CDK for CI pipelines". I.e. declaratively setup a web of CI / deployment tasks, based on docker, with a code-first DSL, instead of the morass of copy-pasted (and yes
22.
by stephen 9mo ago
Thanks for the reply! That all makes sense! As a potential user, I'd probably be thinking through things like: if I have a ~small-fleet of 10 ECS tasks serving my REST/API endpoints, would I run `client.query`s on these same machi
23.
by stephen 9mo ago
Can you description the deployment setup, somewhere in the docs/maybe with a diagram? I get this is a backend library, which is great, but like does it use postgres replication slots? Per the inherited queries, do they all live on 1 ma
24.
by stephen 9mo ago
These two suggestions are fine, but I don't think they make fixtures really that much better--they're still a morass of technical debt & should be avoided at all costs. The article doesn't mention what I hate most about f
25.
by stephen 10mo ago
I still use my index finger; I've just gotten used to moving my hand ~slightly over from j to the nub. I would definitely prefer their trackpoint module be "flipped upside down" so the nub was on top, directly next to the H k
26.
by stephen 10mo ago
The UHK80 has a trackpoint module that works great!
27.
by stephen 11mo ago
Everyone's definition of "production quality" is different :-), but Joist is a "mikro-ish" (more so ActiveRecord-ish) ORM that has a few killer features: https://joist-orm.io/ Always happy to hear f
28.
by stephen 11mo ago
Great to hear you're using postgres.js in prod/large deployments! That sort of real-world-driven usage/improvements/roadmap imo leads to the best results for open source projects. Also interesting about a potential v4! I
29.
by stephen 11mo ago
Oh hello! Very happy to hear from you, and even happier to be wrong about your "AWOL-ness" (since I want to ship postgres.js to prod). :-) My assumption was just from, afaict, the general lack of triage on GitHub issues, i.e. for
30.
by stephen 11mo ago
I really want to use pipelining for our "em.flush" of sending all INSERTs & UPDATEs to the db as part of a transaction, b/c my initial prototyping showed a 3-6x increase: https://joist-orm.io/blog/ini

More ›