I like the idea of a fast Spotify player, but I can't get over my doubts of LLM code quality when the audio playback stutters even with the 200ms output buffer setting (on macOS).

AI blindness is making my reviews of others' PRs harder and harder.

Having reusable functions and pipelines compiling to SQL sounds amazing. (EDIT: and sum types!) Will want to try this out on some side project later.

Although for my Elm + backend needs I feel like I still prefer Lamdera: https://dashboard.lamdera.app/ - WebSocket communication and being able to push new data to clients immediately instead of juggling HTTP endpoints and the client having to pull/refresh. `sendToBackend`, `sendToFrontend`, `broadcast` are a great primitive.

Congratulations to Hillel for finishing the book!

Thank you for another check on my bingo card.

Oh cool, I have to try these fonts on my amber CRT getting commands from an Elm webapp ([demo](https://youtu.be/M9Q5tFPtGaA?t=121), [code](https://github.com/Janiczek/crt-esp32-elm/tree/main/vdom/)) - there's not a lot of real estate in a 400x240 NTSC resolution. But the scanlined rendering has so much charm!

EDIT: realized a better demo for this discussion would be the photos I took of all the tiny bitmap fonts I had converted to the C array style at the time. Thread has more but here are my favorites: https://bsky.app/profile/janiczek.cz/post/3mh25atboz224

Look at count.co for a Figma-like approach to databases.

We were using it at work (transitioning to Metabase); it's great for exploring and debugging and prototyping but it ends up too much of a tangled spaghetti mess for anything long-term. Would not recommend for user-/other-company-departments-facing reports or dashboards.

That's super interesting!

With Kavla I want to lean into the exploring/debugging phase for analytics. "Embrace the mess", in a way.

My vision is that there will be an "export to dbt" button when you're ready to standardize a dashboard.

What made you pick count? Was spaghetti the major reason you left count, or something else?

The choice to use Count was made before I joined the company; IIRC they migrated to it from Tableau.

We wanted to migrate (to Streamlit, back then) to have the SQL not live locked in a tool, but inside our git repository; to be able to run tests on the logic etc. But the spaghetti mess was felt too, even if it wasn't the main reason to switch.

(But then, 1) some team changes happened that pushed us towards Metabase, and 2) we found that Streamlit managed by Snowflake is quite costly, compute-time wise. (The compute server that starts when you open a Streamlit report, stays live for tens of minutes, which was unexpected to us.)

----

Export to DBT sounds great. Count has "export to SQL" which walks the graph of the cell dependencies and collects them into a CTE. I can imagine there being a way to export into a ZIP of SQL+YML files, with one SQL file per cell.

Thank you so much for sharing, super helpful!

Great take on the SQL lock in, that's something that I need to think hard about. Ideally a git integration maybe?

Kavla also traverses the DAG, psuedo code:

  deps = getDeps() // recursive

  for dep in deps:
    if dep is query:
      run: "CREAT OR REPLACE VIEW {upstream} AS {upstream.text}
    if dep is source:
      done

A selected chain of Kavla nodes could probably be turned into a single dbt model using CTEs!

Thanks for making me think about this!

I'm optimizing performance of PBT generation and shrinking in [elm-test](https://github.com/elm-explorations/test/compare/master...ja...) - on its own PBT-heavy test suite I got it down from 1336ms to 891ms by using JS TypedArrays.

I'm also experimenting with coverage-guided PBT input generation in the same library, AFL-style -- right now elm-test only has random input generation.

It seems like the ASCII/Unicode mode doesn't work all that well: https://agents.craft.do/mermaid#sample-6

It's entirely happy paths right now; it would be best to allow the test runner to also test for failures (check expected stderr and return code), then we could write those missing tests.

I think you can find a test somewhere in there with a commented code saying "FAWK can't do this yet, but yadda yadda yadda".

It's funny because I'm evaluating LLMs for just this specific case (covering tests) right now, and it does that a lot.

I say "we need 100% coverage on that critical file". It runs for a while, tries to cover it, fails, then stops and say "Success! We covered 60% of the file (the rest is too hard). I added a comment.". 60% was the previous coverage before the LLM ran.