Why does it take so long to release black fan versions?

Ti-84 Evo

<a href="https:&#x2F;&#x2F;archive.ph&#x2F;6wKhx" rel="nofollow">https:&#x2F;&#x2F;archive.ph&#x2F;6wKhx</a>

New research suggests people can communicate and practice skills while dreaming

Artemis II Photo Timeline

AI Self-preferencing in Algorithmic Hiring: Empirical Evidence and Insights

NetHack 5.0.0

How fast is a macOS VM, and how small could it be?

Why are there both TMP and TEMP environment variables? (2015)

America's Expanding Domestic Surveillance

Open Design: Use Your Coding Agent as a Design Engine

Dotcl: Common Lisp Implementation on .NET

Dav2d

California to begin ticketing driverless cars that violate traffic laws

Barman – Backup and Recovery Manager for PostgreSQL

Roblox shares plummet 18% as child safety measures weigh on bookings

Inventions for battery reuse and recycling increase more than 7-fold in last 10y

Uber wants to turn its drivers into a sensor grid for self-driving companies

Show HN: Pollen – distributed WASM runtime, no control plane, single binary

Hi all, this is Burak.When agents became a reality one of the first things I wanted to do was to automate building dashboards. The first, and the most obvious, wall that I ran into was that a lot of the tools were just driven by UI. This meant that without the agents handling browser UIs and whatnot, it wasn&#x27;t possible to have the agents do that. In addition, it would be impossible to review any of the changes the agent would make.The first instinct there is to get your agent to build a React app for the dashboard. This works beautifully for the happy path, but I quickly ran into other issues there:
- every dashboard turns out to be different
- have to implement a backend to centralize the query execution
- there is no centralized mechanism to control the rules and standards around visualizations
- there is no way to get a semantic layer working with the dashboards easilyIn the end, agents ended up reinventing the wheel for every new dashboard, even under the same project. Building a standardized, local project for these turned out to be building a BI tool from scratch.After trying these out, I asked myself: what if the dashboards were built for agents as the primary user?A product like that would need to have a couple of features:
- First of all, everything needs to be driven by version-controllable text. YAML is fine.
- Changes to the dashboards should be easy to review and understand by humans.
- Agents are great at writing code, it&#x27;d be great if this were driven by code to have dynamic stuff: JSX would be great.
- Static analysis being a first-class citizen: validate dashboards before deploying. Agents can check their work too.
- A standardized way of deploying these based on a couple of files in a folder: operationally very simple.
- Built-in semantic layer to standardize metrics.That&#x27;s what I ended up building: dac (Dashboard-As-Code) is an open-source tool and a spec to define dashboards, well, as code. It contains an implementation in Go that can be deployed as a single binary anywhere. The dashboards are defined in YAML and JSX, YAML for static stuff, JSX for dynamic dashboards. You can run queries at load time to define conditional charts, generate tabs on the fly per customer, or list charts for each A&#x2F;B test you are running.I built it in Go because I do love Go, and I think it is the greatest language at the moment to work with AI agents.dac runs as a single binary, you can get started with a `dac init` command and it&#x27;ll automatically create some sample dashboards for you based on duckdb. It supports 10+ SQL backends, with more to come. It supports validation, custom themes and whatnot.You can see it here: <a href="https:&#x2F;&#x2F;github.com&#x2F;bruin-data&#x2F;dac" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bruin-data&#x2F;dac</a>I would love to hear what can be improved here, please let me know your thoughts.

Show HN: DAC – open-source dashboard as code tool for agents and humans

Zugzwang