<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Project Spotlight on S3H.com</title>
    <link>https://s3h.com/tags/project-spotlight/</link>
    <description>Recent content in Project Spotlight on S3H.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 02 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://s3h.com/tags/project-spotlight/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AltSql Gives IoT Devices a 15 KB Database That Keeps Working When the Link Drops</title>
      <link>https://s3h.com/altsql-gives-iot-devices-a-15-kb-database-that-keeps-working-when-the-link-drops/</link>
      <pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://s3h.com/altsql-gives-iot-devices-a-15-kb-database-that-keeps-working-when-the-link-drops/</guid>
      <description>&lt;p&gt;Anyone who has built the software side of a connected product knows the glue job. The device keeps its readings in one format and the gateway wants rows in a SQL database, so somebody writes a converter. Then somebody has to keep that converter alive for as long as the device stays in the field, which can easily be ten years.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://altsql.com/&#34;&gt;AltSql&lt;/a&gt; takes the converter out. Its base engine, AltSql Core, compiles to about 15 KB of code for a microcontroller. The device keeps its readings and settings in its own flash and goes on deciding from its own data when the connection goes. Its gateway stores the very same records, byte for byte, and answers SQL over them.&lt;/p&gt;</description>
    </item>
    <item>
      <title>BareProxy Is a Small Go Web Server and Reverse Proxy That Explains Every Routing Decision</title>
      <link>https://s3h.com/bareproxy-is-a-small-go-web-server-and-reverse-proxy-that-explains-every-routing-decision/</link>
      <pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://s3h.com/bareproxy-is-a-small-go-web-server-and-reverse-proxy-that-explains-every-routing-decision/</guid>
      <description>&lt;p&gt;Most sites use a thin slice of nginx: TLS, a folder of static files, a couple of routes to an app, health checks and the odd reload. The config grows anyway, one regex at a time, until nobody is quite sure which block handles a given URL.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://bareproxy.com/&#34;&gt;BareProxy&lt;/a&gt; keeps its core to that slice and makes it answer questions. &lt;code&gt;bareproxy explain&lt;/code&gt; takes a URL and shows which rule matched, which file or backend would serve it, and why the rules above it didn&amp;rsquo;t match. &lt;code&gt;bareproxy why&lt;/code&gt; tells the story of a request that already happened, starting from the ID it carried in a response header.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Precomputing Keeps Dashboard Answers Ready in a SQLite File as the Data Arrives</title>
      <link>https://s3h.com/precomputing-keeps-dashboard-answers-ready-in-a-sqlite-file-as-the-data-arrives/</link>
      <pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://s3h.com/precomputing-keeps-dashboard-answers-ready-in-a-sqlite-file-as-the-data-arrives/</guid>
      <description>&lt;p&gt;Most dashboards ask the same few questions all day long: requests per endpoint, say, or this month&amp;rsquo;s usage for one customer. The usual setup recounts raw rows on every refresh, or ships every row to a hosted service that bills by the gigabyte.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://precomputing.com/&#34;&gt;Precomputing&lt;/a&gt; does the counting once, as the data comes in. You write a short policy that names the answers you want and says how long each level of detail should live. It compiles to plain SQLite triggers, so every INSERT keeps those answers current and reading one is a lookup. Old detail fades on your schedule; unusual events are kept whole.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Preconfiguration Writes Coding Agent Setup Files From One Spec and Tests Them on a Clean Machine</title>
      <link>https://s3h.com/preconfiguration-writes-coding-agent-setup-files-from-one-spec-and-tests-them-on-a-clean-machine/</link>
      <pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://s3h.com/preconfiguration-writes-coding-agent-setup-files-from-one-spec-and-tests-them-on-a-clean-machine/</guid>
      <description>&lt;p&gt;Cloud coding agents start each task on a fresh machine. Before the agent can run a single test, something has to install the right runtime and start the database, and every platform wants those instructions in its own file. Copilot runs a setup workflow; Cursor builds a Dockerfile. A team that uses two or three agents writes the same setup two or three times, and a mistake usually shows up later as an agent session that goes nowhere.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
