I think what I'm trying to understand is this: if I use EdgeDB in production, how often will I end up dropping down to the SQL level to debug things? If I'm trying to debug a slow query, can I do it at the EdgeDB level? Or will I have to open a PostgreSQL terminal, see how things are laid out there, run EXPLAINs, check the slow query log, and so on?
When I use ORMs, the answer to this is "pretty often". The ORM makes my application code cleaner, but I still need to have a complete understanding of the underlying SQL representation in order to ensure good performance and debug errors. I'm curious how that compares to using EdgeDB.
I'm wondering about the physical level—or at least how the EdgeDB conceptual level is translated to the Postgres conceptual level. The docs, and the comment you linked to, have helped me get pretty clear about the EdgeDB conceptual level.
What's a good way to develop a mental model about what's happening under the hood in EdgeDB?
With SQL, I have a mental model of how things work under the hood. For instance, I think of each table as being stored separately on disk, containing "rows". And the rows are really just equally-sized data blocks that are laid out back to back. B+ trees, with leaf nodes that point to (or just are) the rows, are used for indexes.
When I'm designing SQL schemas, I use this mental model to make guesses about performance. And when my queries are slow, I look at the execution plan.
My question is, how can I develop a similar intuition about EdgeDB? Under the hood, how are types and links stored in Postgres? And if I'm having performance issues, can I see an execution plan?
That's right, it's essentially sandboxing the scripts. But I think the real innovation is an automated system they've created for writing the sandboxing code based on tracing the execution of the malicious/ad scripts in the browser.
Otherwise, what you're saying would be true, and this could be easy to break/bypass.
Correct. I am a Canadian who recently traveled to Canada. I filled AriveCAN out at home, printed it out, and brought the printed receipt to the border.
With a traditional interview and job offer process, a new employee can ramp up without worrying their job is on the line. And I think this is important, because it can take awhile to ramp up to full productivity, which can be stressful if the new employee feels like they're being evaluated already.
Where I've worked, my new manager told me "Hey, welcome to the company. Please feel relaxed and take your time ramping up, you've already passed the interview and we're happy to have you here."
With your process, how do you deal with people getting stressed out during ramp up or feeling imposter syndrome?
There's another github link (https://github.com/oreilly-japan/deep-learning-from-scratch-...) with the code for all 60 steps, but not the explanatory text.