<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Use Cases on ukue.com</title>
    <link>https://ukue.com/tags/use-cases/</link>
    <description>Recent content in Use Cases 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/tags/use-cases/index.xml" rel="self" type="application/rss+xml" />
    <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>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>
  </channel>
</rss>
