vega-lite VS hitchstory

I like Vega-Lite: https://vega.github.io/vega-lite/

It’s built by folks from the same lab as D3, but designed as “a higher-level visual specification language on top of D3” [https://vega.github.io/vega/about/vega-and-d3/]

My favorite way to prototype a dashboard is to use Streamlit to lay things out and serve it and then use Altair [https://altair-viz.github.io/] to generate the Vega-Lite plots in Python. Then if you need to move to something besides Python to productionize, you can produce the same Vega-Lite definitions using the framework of your choice.

Box zoom would need to be added to Vega-Lite first, and there has been some discussion around it in https://github.com/vega/vega-lite/issues/4742. Bottom line is that there's nothing blocking its implementation, someone just needs to do the work in Vega-Lite. And once released in Vega-Lite, Altair would pick it up automatically with how we generate the Altair API from the Vega-Lite schema.

I also have difficulties with Gnuplot and Matplotlib. I like Vega that allows me to create visualisations in a declarative way. If I really need something special I go with d3.js, which had a really steep learning curve but with ChatGPT it should have become easier for beginners.

[1] https://vega.github.io/vega-lite/

To ensure you do not miss this: LiveBook comes with a Vega Lite integration (https://livebook.dev/integrations -> https://livebook.dev/integrations/vega-lite/), which means you get access to a lot of visualisations out of the box, should you need that (https://vega.github.io/vega-lite/).

In the same "standing on giant's shoulders" stance, you can use Explorer (see example LiveBook at https://github.com/elixir-explorer/explorer/blob/main/notebo...), which leverages Polars (https://www.pola.rs), a very fast DataFrame library and now a company (https://www.pola.rs/posts/company-announcement/) with 4M$ seed.

Nice, would be nice to have it integrated in GitHub markdown.

Looks similar to Vega or Vega-lite(https://vega.github.io/vega-lite/). Definitely as rich as D3.js but gets the job done for simple visualisations.

Vega-lite can do this https://vega.github.io/vega-lite/

The underlying data is from an online betting site. Data analysis was done in Python and I used Vega/Altair for the visualisation.

I have a bunch of data that I want to plot. I'm using lisp-stat, which is pretty good, for data frames and analysis. However, lisp-stat uses vega-lite for plotting and to put it mildly, vega-lite is fucking awful.

I built something like this too:

https://github.com/hitchdev/hitchstory/blob/master/examples%...

I took the same approach to "docs are tests and tests are docs" with integration testing when I created this library: https://github.com/hitchdev/hitchstory

I realized at some point that a test and a how-to guide can and should actually be the same thing - not just for doctests, but for every kind of test.

It's not only 2x quicker to combine writing a test with writing docs, the test part and the docs part reinforce each other:

* Tests are more easily understandable when you attach written context intended for human consumption.

* Docs are better if they come attached to a guarantee that they're valid, not out of date and not missing crucial details.

* TDD is better if how-to docs are created as a side effect.

I have created a project for easily writing this type of test with YAML:

https://github.com/hitchdev/hitchstory

I dont think that this type of task is really appropriate for an LLM though. It is better to use hard abstractions for the truly deterministic stuff and for other stuff where you may need to do subtle trade offs (e.g. choosing a selector for the search bar) an LLM will generally do a bad job.

For those interested in the concept of having permanently up-to-date documentation with screenshots I built this testing framework based upon the idea that good documentation can be a autogenerated artefact of good tests:

https://github.com/hitchdev/hitchstory

I don't like gherkin. It's it has very awkward syntax, it's not type safe, it's very verbose, it has no ability to abstract scenarios and rather than being a source for generating the documentation it tries to be the documentation.

Nonetheless, there is a small number of projects where they either work around this or it doesn't matter as much. I find that most people that apply gherkin to their projects find it doesn't work - usually for one of the above reasons.

I built https://github.com/hitchdev/hitchstory as an alternative that has straightforward syntax (YAML), very strict type safety (StrictYAML), low verbosity, and is explicitly designed as a source for generating documentation rather than trying to be the documentation.

I built this because I had the same idea: https://github.com/hitchdev/hitchstory

If the specification can be tested and used to generate docs and can be rewritten based upon program output then the maintenance cost for producing docs like these plunges.

-c fsync=off -c synchronous_commit=off -c full_page_writes=off

I got the answer from Karen Jex at Djangocon 2023.

I used it to build some integration tests which exhibit best practices: https://github.com/hitchdev/hitchstory/tree/master/examples/...

I considered using tmpfs but I wanted to cache the entire database volume and couldnt figure out how to do that with podman.

This is incredible work.

To anyone curious, I highly recommend:

- https://hitchdev.com/hitchstory/approach/

- https://hitchdev.com/hitchstory/why-not/

From the overall RDD/BDD type home page:

- https://hitchdev.com/hitchstory/

The entire product site is a thing of richly informative beauty.

---

My only question was whether the generated 'docs' snippets would add value over just reading the story in your DASL. Any markdown site generator (such as the chosen Material for MKDocs) can just embed the ```yaml anyway. But then I realized what was generating e.g. …

- https://hitchdev.com/hitchstory/using/engine/rewrite-story/

… and how superior that is to typical docs, especially typical docstring or swagger factories.