<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on ukue.com</title>
    <link>https://ukue.com/posts/</link>
    <description>Recent content in Posts on ukue.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 06 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ukue.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Job Queue in One SQLite File: ukue 0.1 Lets Small Teams Skip Redis</title>
      <link>https://ukue.com/a-job-queue-in-one-sqlite-file-ukue-0.1-lets-small-teams-skip-redis/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/a-job-queue-in-one-sqlite-file-ukue-0.1-lets-small-teams-skip-redis/</guid>
      <description>&lt;p&gt;Sooner or later every web app needs to do something outside the request. Send the welcome email after the user has seen the page. Resize the photo while they carry on. Retry the webhook when the other side is down. The standard way to do that is a job queue, and the standard way to get a job queue is to run Redis or RabbitMQ next to your app.&lt;/p&gt;&#xA;&lt;p&gt;ukue 0.1 puts the whole queue in one file instead. It&amp;rsquo;s a SQLite database with a documented layout, and it holds every queue, every waiting job, every retry and every job that failed for good. A Go program imports ukue as a library. Everything else uses the one small &lt;code&gt;ukue&lt;/code&gt; binary, which runs a script for each job or serves a small HTTP API.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Raspberry Pi on a Patchy Connection: Readings Wait in a ukue File Until the Internet Is Back</title>
      <link>https://ukue.com/a-raspberry-pi-on-a-patchy-connection-readings-wait-in-a-ukue-file-until-the-internet-is-back/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/a-raspberry-pi-on-a-patchy-connection-readings-wait-in-a-ukue-file-until-the-internet-is-back/</guid>
      <description>&lt;p&gt;Think of a market garden with three greenhouses, each with temperature, humidity and soil sensors wired to a Raspberry Pi. Every minute the Pi reads the sensors and sends the numbers to a dashboard in the cloud, where the grower checks them on a phone and gets an alert if a greenhouse overheats. The internet comes from a 4G router on a pole, and it drops out: a few minutes in bad weather, half a day when the mast is down. A script that simply posts each reading loses every minute the connection is gone.&lt;/p&gt;</description>
    </item>
    <item>
      <title>AI Transcription on a Rented GPU: Python Workers Pull Jobs From ukue Over HTTP</title>
      <link>https://ukue.com/ai-transcription-on-a-rented-gpu-python-workers-pull-jobs-from-ukue-over-http/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/ai-transcription-on-a-rented-gpu-python-workers-pull-jobs-from-ukue-over-http/</guid>
      <description>&lt;p&gt;Say a small podcast-hosting service wants to offer transcripts. Speech-to-text models are quick on a GPU and painfully slow without one, and the service&amp;rsquo;s web server is a modest cloud machine with no GPU. So it rents a GPU server by the month from another provider, and needs a way to hand it work: here&amp;rsquo;s an episode, transcribe it, report back when it&amp;rsquo;s done. Episodes are long, so one job can take ten minutes. And the GPU server might be restarted, or swapped for a bigger one, at any time.&lt;/p&gt;</description>
    </item>
    <item>
      <title>An Order and Its Receipt Email in One SQLite Transaction With ukue&#39;s EnqueueTx</title>
      <link>https://ukue.com/an-order-and-its-receipt-email-in-one-sqlite-transaction-with-ukues-enqueuetx/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/an-order-and-its-receipt-email-in-one-sqlite-transaction-with-ukues-enqueuetx/</guid>
      <description>&lt;p&gt;Take a small online shop that runs as a single Go program with its data in SQLite: one file to back up and no database server to look after. When an order comes in, the shop saves it, and a receipt email goes out in the background.&lt;/p&gt;&#xA;&lt;p&gt;The risk is in the gap between those two steps. If the order is saved and the program crashes before the email job is queued, the customer pays and never gets a receipt. If the job is queued first and saving the order then fails, the customer gets a receipt for an order that doesn&amp;rsquo;t exist. With a separate queue server, closing that gap takes real work, usually an &amp;ldquo;outbox&amp;rdquo; table in the database and a second process that copies its rows into the queue. With ukue, the queue can live inside the shop&amp;rsquo;s own database, so the order and its job go into the same transaction, and either both are saved or neither is.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Appointment Reminders With ukue: Jobs Scheduled Days Ahead, Deleted When a Booking Moves</title>
      <link>https://ukue.com/appointment-reminders-with-ukue-jobs-scheduled-days-ahead-deleted-when-a-booking-moves/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/appointment-reminders-with-ukue-jobs-scheduled-days-ahead-deleted-when-a-booking-moves/</guid>
      <description>&lt;p&gt;Picture a hair salon in London that takes bookings online, weeks ahead, and texts every client a reminder 24 hours before the appointment. No-shows cost it money, so the reminders matter. The obvious way to send them is a cron job that wakes up every few minutes and searches the bookings for appointments about a day away. That works until two runs overlap and a client gets two texts, or the server is down at the wrong moment and an hour of reminders never goes out, or a booking moves and the reminder still names the old time.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Checking 300 Websites Every Night With ukue, Cron and a Shell Script</title>
      <link>https://ukue.com/checking-300-websites-every-night-with-ukue-cron-and-a-shell-script/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/checking-300-websites-every-night-with-ukue-cron-and-a-shell-script/</guid>
      <description>&lt;p&gt;Say a two-person web agency looks after 300 client websites. Each morning they want to know which sites were down overnight and which TLS certificates are close to expiring, before a client calls about it. Monitoring services do this for a monthly fee per site. The agency already has a Linux server, a text file of domains and a shell script that checks one site, and would rather not add anything bigger than that.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How the ukue Job Queue Was Tested: 250 Killed Workers, 0 Lost Jobs</title>
      <link>https://ukue.com/how-the-ukue-job-queue-was-tested-250-killed-workers-0-lost-jobs/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/how-the-ukue-job-queue-was-tested-250-killed-workers-0-lost-jobs/</guid>
      <description>&lt;p&gt;A job queue makes one promise above all others: a job that was added runs, even if the machine has a bad day. So the most important tests for ukue don&amp;rsquo;t check the happy path. They kill workers in the middle of their work and look at what&amp;rsquo;s left.&lt;/p&gt;&#xA;&lt;p&gt;The tests run on every change to the code, on Linux and macOS, and the recorded output is published with the code in &lt;a href=&#34;https://github.com/ukue-queue/ukue/tree/main/test/results&#34;&gt;test/results&lt;/a&gt;. The numbers below come from the recorded run, on a two-core cloud machine.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Photo Upload Thumbnails With ukue: Previews First, Print Sizes When the CPU Is Free</title>
      <link>https://ukue.com/photo-upload-thumbnails-with-ukue-previews-first-print-sizes-when-the-cpu-is-free/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/photo-upload-thumbnails-with-ukue-previews-first-print-sizes-when-the-cpu-is-free/</guid>
      <description>&lt;p&gt;Take a portfolio site where photographers upload full-size JPEGs after a shoot, a few hundred at a time and 20 or 30 megabytes each. Every photo needs three resized copies: a 400-pixel thumbnail for the gallery grid, a 1600-pixel version for the lightbox, and a 3000-pixel file for print orders. Resizing a big JPEG takes real CPU time, and doing it inside the upload request turns a 300-photo upload into a long wait behind a progress bar that seems stuck.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Signup Emails From a Python Web App, Sent in the Background With ukue</title>
      <link>https://ukue.com/signup-emails-from-a-python-web-app-sent-in-the-background-with-ukue/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/signup-emails-from-a-python-web-app-sent-in-the-background-with-ukue/</guid>
      <description>&lt;p&gt;Say a three-person team runs a Flask app where people book cooking classes. Every new account gets a welcome email, and today the app sends it inside the signup request. On a good day that adds a second or two to the page. On a bad day the mail provider is slow or down, the request hangs, and a new customer sees an error on the first thing they ever tried to do on the site.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Webhook Delivery With ukue: A Day of Retries, Then Dead Letters Instead of Lost Events</title>
      <link>https://ukue.com/webhook-delivery-with-ukue-a-day-of-retries-then-dead-letters-instead-of-lost-events/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/webhook-delivery-with-ukue-a-day-of-retries-then-dead-letters-instead-of-lost-events/</guid>
      <description>&lt;p&gt;Say a small company runs an invoicing service written in Go. Its customers want to hear about payments the moment they happen, so the service sends webhooks: an HTTP POST with the event to a URL each customer chooses. Those URLs point at servers the company doesn&amp;rsquo;t control. They go down for maintenance, get redeployed, hit rate limits and return errors. If the service sends each webhook once, straight from the code that records the payment, every one of those hiccups loses an event, and the customer finds out weeks later when their books don&amp;rsquo;t add up.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is a Job Queue? Background Jobs, Retries and Dead Letters Explained</title>
      <link>https://ukue.com/what-is-a-job-queue-background-jobs-retries-and-dead-letters-explained/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/what-is-a-job-queue-background-jobs-retries-and-dead-letters-explained/</guid>
      <description>&lt;p&gt;A job queue is a to-do list for software. When something has to happen but doesn&amp;rsquo;t have to happen right now, a program writes it on the list and moves on. A separate worker takes items off the list and does them. That&amp;rsquo;s the whole idea, and almost every web app ends up needing it.&lt;/p&gt;&#xA;&lt;p&gt;Take a sign-up form. When a user signs up, the app has to save the account, send a welcome email, and maybe tell the sales team&amp;rsquo;s CRM. Saving the account is quick. Talking to a mail server can take seconds, and it might be down. Making the user stare at a spinner while that happens is a poor trade, so the app saves the account, adds &amp;ldquo;send a welcome email to Dana&amp;rdquo; to a job queue, and shows the next page at once. A worker sends the email a moment later.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why u Stands for Micro: How the ukue Job Queue Got Its Name</title>
      <link>https://ukue.com/why-u-stands-for-micro-how-the-ukue-job-queue-got-its-name/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/why-u-stands-for-micro-how-the-ukue-job-queue-got-its-name/</guid>
      <description>&lt;p&gt;ukue is meant to be read as µkue, a micro queue. Plenty of people will say &amp;ldquo;you-queue&amp;rdquo; instead, and that&amp;rsquo;s fine. The u is a stand-in for the real sign of micro, the Greek letter μ, and the story of how one turned into the other is older than computers.&lt;/p&gt;&#xA;&lt;p&gt;Micro comes from the Greek &lt;em&gt;mikrós&lt;/em&gt;, &amp;ldquo;small&amp;rdquo;, and in Greek that word starts with μ, their letter m. When the metric system gave its prefixes one-letter symbols, the Latin m was already taken by milli, a thousandth. So micro, a millionth, got the Greek m. That&amp;rsquo;s why a microsecond is written µs and a microfarad µF.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
