Have you thought about how these dashboards could be built for an eink screen?<p>For a while, I was thinking about starting a side project of selling E-ink screens with easily configured dashboards. The project would support hobbies who want to build dashboards powered by a raspberry pi or something. I never pursued it, but it seems like you are now halfway there.
Why not use Vega-Lite[0]? It’s my go-to data viz DSL with Claude.<p>[0] <a href="https://vega.github.io/vega-lite/" rel="nofollow">https://vega.github.io/vega-lite/</a>
There are quite a few libraries for charts and visualization, there are not as many for actually combining many of them with layouts, different components and including the actual implementation of the backend. Dac aims to provide all that as a standard and an implementation.
I mean that's what the Vega team is doing no? They are building the standard grammar (Vega-Lite), along with an implementation (Vega). And they are already quite established with rich ecosystem, and supports a ton of components[0]. The only thing missing is that it expects a CSV or inline data source. But it's probably not too hard to build an extension that connects to a data warehouse with an SQL query.<p>[0] <a href="https://vega.github.io/vega-lite/examples" rel="nofollow">https://vega.github.io/vega-lite/examples</a>
DaC might be more distinguishable from DAC, although the context obviously also helps readers telling them apart.<p>Yours sincerely, came here for another DAC
Consider adding that snazzy gif in the README to the docs landing page. I went straight to the docs and then hunted for a screenshot to no avail.
I would really hesitate to use a 1000 lines of yaml and modify them. I never found YAML easy to modify after a certain size.
Why do ppl think building something through yaml is ever a good idea??<p>(I know why: for a platform it’s simpler to parse a yaml than to run code, but it’s almost never a good idea for anything that needs to scale in complexity)
What is a better format that allows inline comments, is human readable, and can be easily converted to other formats (json, xml, et al)
The comments are why I prefer YAML for config over JSON. Of course, JSON is great for many purposes, especially machine to machine. For human to machine, I prefer YAML.
Semantic layer + validation is the interesting part imo, everything else is table stakes. would lead with that
I reckon this is a simplification of existing BIAC tools (eg, <a href="https://github.com/lightdash/lightdash" rel="nofollow">https://github.com/lightdash/lightdash</a>)
The blurb about this is repeated several times but it is unclear to me what it actually does.
Might want to add how this compares to other products in the space.<p>Some that come to mind that are potentially tangentially related/similar:<p><a href="https://github.com/evidence-dev/evidence" rel="nofollow">https://github.com/evidence-dev/evidence</a>
[dead]
[flagged]
[flagged]
[flagged]