Who does things like that?!?

Apparently: me.

I have my own project, written in Rust. Not a big one, mind you, maybe approx. 30k lines of code in total. Rust is verbose so it’s not really that impressive. I’ve put it aside for some time and was toying with local inference, LLMs, writing agents and my attention was brought to Ruby.

It’s been a while. So I had to take a look around to remind myself what Ruby and Ruby on Rails are doing nowadays. They’re doing quite well. There are some typing initiatives (Sorbet), and the language itself is terse as ever.

And then I had this thought… But an introduction is in order first: In my Rust app I have an isolated crate that’s pretty much a webapp written with Tera and Axum. 14,943 lines of Rust code in total, around 10s of compilation time (maybe the code isn’t big, but it pulls the whole universe behind itself) and then quite heavy E2E tests involving setting up Playwright and (because of the near-impossibility of mocking) an isolated database namespace and mocking services (along with a very special internal-api crate that allows Playwright to interact with the app in headless mode…).

So I thought “hmm, I wonder if I can get my Local Qwen3.6 to do a oneshot conversion”. But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).

 ┌─────────────────────────────────┬──────────────────┬───────┬────────────────┐
 │ Area                            │ Rust/Axum/Diesel │ Rails │ Rails + Sorbet │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Suitability for solo dev        │ 60               │ 90    │ 85             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Development speed               │ 40               │ 90    │ 75             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Safety                          │ 95               │ 55    │ 80             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Development complexity          │ 70               │ 90    │ 75             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Performance                     │ 95               │ 50    │ 50             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Boilerplate                     │ 30               │ 85    │ 80             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ E2E testing testability         │ 40               │ 75    │ 75             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Unit testability                │ 20               │ 90    │ 90             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Integration testing testability │ 30               │ 85    │ 85             │
 ├─────────────────────────────────┼──────────────────┼───────┼────────────────┤
 │ Sum                             │ 480              │ 710   │ 695            │
 └─────────────────────────────────┴──────────────────┴───────┴────────────────┘

So in the end it seems I have (licks finger and turns to the wind) 1.47x better outcomes if the app were a Ruby on Rails app instead.

I have a local LLM running on my (bought it for gaming pre-AI craze) 4090 Ti¹ - I’m a free man with unlimited tokens². So I thought: BRING IT ON!

Since it is a relatively small project the conversion took ~30 minutes. I have no idea if it works or not because I haven’t yet tried running it. But there is one thing I checked, and stared at in horror:

$ fd . -e rs -uu | xargs cat | wc -l
   14943
$ fd . -e rb -uu | xargs cat | wc -l
    3322

That’s right folks! 77% decrease in line count; 4.49 lines of Rust code for each line of Ruby.

I browsed the Ruby code and it looks… fine. There are probably some bugs (no bunnies) but I must say it’s looking clean and idiomatic for my dated eye. I’m going to examine it further with some things in mind:

• I can add types using Agents, so probably type safety can be alleviated

• Ruby/Rails is pretty much batteries+kitchen sink included, which beats 3GiB of compiled deps.

• Testing will be SO MUCH EASIER

     VCR.use_cassette("llm_call") do
       result = LlmClient.match(entry, data_list)
       expect(result.results.size).to eq(data_list.size)
     end
  

  vs

  #[derive(Debug)]
  pub struct MockProvider {
    responses: Arc<RwLock<Vec<Response>>>,
    call_count: Arc<AtomicUsize>,
  }
  
  impl Default for MockProvider {
    fn default() -> Self {
      Self {
        responses: Arc::new(RwLock::new(vec![Response::default()])),
        call_count: Arc::new(AtomicUsize::new(0)),
      }
    }
  }
  
  impl MockProvider {
    pub fn new(responses: Vec<Response>) -> Self {
      Self {
        responses: Arc::new(RwLock::new(responses)),
        call_count: Arc::new(AtomicUsize::new(0)),
      }
    }
  }
  
  #[async_trait]
  impl Provider for MockProvider {
    async fn match(&self, entry: &Entry, data_list: &[Data]) -> Result<MatchResult> {
      self.call_count.fetch_add(1, Ordering::SeqCst);
      let responses = self.responses.read().await;
      Ok(MatchResult { results: responses.clone() })
    }
  }
  
  #[cfg(test)]
  mod tests {
    use super::*;
  
    #[tokio::test]
    async fn test_mock_provider_returns_expected_results() {
      let expected = vec![Response::default()];
      let provider = MockProvider::new(expected.clone());
      let result = provider.match(&Entry::default(), &[]).await.unwrap();
      assert_eq!(result.results, expected);
      assert_eq!(provider.call_count.load(Ordering::SeqCst), 1);
    }
  }
  

  …you get the vibe, right?

The benefits of working on your own project are, well, you can make crazy decisions, and I’ll be looking at this one very closely.

🎯 BEMoji v1.0.0-beta

RFC DRAFT

<!-- A card component in BEMoji -->

<article class="🃏">

  <div class="🃏__🖼️ 🃏__🖼️--🌟">
    <img src="hero.jpg" alt="...">
  </div>

  <div class="🃏__📝">
    <h2 class="🃏__🔠">Card Title</h2>
    <p class="🃏__💬">Card description text</p>
  </div>

  <footer class="🃏__🦶">
    <button class="🔘 🔘--🌟">Primary</button>
    <button class="🔘 🔘--👻">Disabled</button>
  </footer>

</article>

<!-- Responsive: 📱 = mobile-only -->
<div class="📐💠 💻📐🔲">
  Grid col-1 on mobile, col-2 on desktop
</div>

/* ── Card Block ── */
.🃏 {
  border-radius: 8px;
  overflow: hidden;
  box-shadow: var(--🌑-md);
  background: var(--⬜);
}

/* Element: image */
.🃏__🖼️ {
  width: 100%;
  aspect-ratio: 16 / 9;
  overflow: hidden;
}

/* Modifier: featured */
.🃏__🖼️--🌟 {
  outline: 3px solid var(--⭐-gold);
  outline-offset: -3px;
}

/* Design tokens use emoji too */
:root {
  --⬜: #ffffff;
  --⬛: #0d0d0f;
  --🌑-sm: 0 1px 3px rgba(0,0,0,.12);
  --🌑-md: 0 4px 12px rgba(0,0,0,.15);
  --📏-1: 0.25rem;
  --📏-4: 1rem;
  --📏-8: 2rem;
}

// bemoji.config.js
export default {
  version: '1.0',

  /** Map readable names → emoji tokens */
  blocks: {
    card:    '🃏',
    navbar:  '🧭',
    modal:   '🪟',
    alert:   '🔔',
    form:    '📋',
    table:   '📊',
  },

  elements: {
    image:   '🖼️',
    title:   '🔠',
    body:    '📝',
    footer:  '🦶',
    button:  '🔘',
    input:   '📥',
  },

  modifiers: {
    primary: '🌟',
    danger:  '🔴',
    success: '🟢',
    ghost:   '👻',
    loading: '⏳',
  },

  separator: {
    element:  '__',
    modifier: '--',
  }
};

// With the Babel transform, write readable
// BEM names — they compile to emoji at build time.

import { bem } from 'bemoji/react';

const Card = ({ featured, children }) => (
  <article className={bem('card')}>
    <div className={bem('card__image', {
      featured
    })}>
      {children.image}
    </div>
    <div className={bem('card__body')}>
      {children.body}
    </div>
  </article>
);

// Compiles to:
// className="🃏"
// className="🃏__🖼️ 🃏__🖼️--🌟"  (when featured)
// className="🃏__📝"

/* Generated by the BEMoji compiler */

@media (min-width: 640px) {
  .\01F4DF \01F4D0 \01F532 { grid-template-columns: repeat(2, 1fr); }
}

@media (min-width: 1024px) {
  .\01F4BB \01F4D0 \01F533 { grid-template-columns: repeat(3, 1fr); }
}

/* Or with modern emoji CSS (most environments) */

@media (min-width: 640px) { .📟📐🔲 { grid-template-columns: repeat(2, 1fr); } }
@media (min-width: 1024px) { .💻📐🔳 { grid-template-columns: repeat(3, 1fr); } }

// postcss.config.js
module.exports = {
  plugins: [
    require('bemoji-postcss')({
      config: './bemoji.config.js',
      escape: 'auto',   // 'raw' | 'unicode'
      sourceMap: true,
    })
  ]
}

// vite.config.ts
import bemoji from 'vite-plugin-bemoji';

export default {
  plugins: [
    bemoji({
      config: './bemoji.config.js',
      include: ['**/*.{tsx,jsx,vue,html}'],
    })
  ]
}

// .vscode/settings.json
{
  "bemoji.showTooltips": true,
  "bemoji.autocomplete": "emoji+readable",
  "bemoji.lintUnknownTokens": "warn",
  "bemoji.hoverFormat": "both",
  "bemoji.configPath": "./bemoji.config.js"
}

// .eslintrc.js
{
  "plugins": ["bemoji"],
  "rules": {
    "bemoji/no-unknown-tokens": "error",
    "bemoji/no-orphan-elements": "warn",
    "bemoji/no-modifier-without-base": "error",
    "bemoji/prefer-semantic-emoji": "warn"
  }
}

import { bem } from 'bemoji/react';

// Runtime usage
bem('card')              // → '🃏'
bem('card__image')       // → '🃏__🖼️'
bem('card', { primary }) // → '🃏 🃏--🌟'
bem('card__image', {
  featured: true,
  loading: false         // → '🃏__🖼️ 🃏__🖼️--🌟'
})

npx bemoji init           # Scaffold + config
npx bemoji compile        # Transform CSS files
npx bemoji audit          # Check for unused tokens
npx bemoji export --fmt json > tokens.json
npx bemoji storybook      # Generate component stories
npx bemoji decode "🃏__🖼️--🌟"
# → card__image--featured

npm install bemoji
# or
yarn add bemoji
# or
pnpm add bemoji

npx bemoji init

# Creates:
# ├── bemoji.config.js
# ├── bemoji.css (base styles)
# └── postcss.config.js

/* main.css */
@import 'bemoji/base';
@import 'bemoji/tokens';
@import 'bemoji/components';

/* Then write your own BEM: */
.[card] { border-radius: var(--⭕-md); }
.[card__image--featured] {
  outline: 2px solid var(--🟡);
}

Nicolas Seriot

Computation > Jira is Turing-Complete

Building a Minsky Machine in Atlassian Automation
22nd May 2026

Engineering folklore holds that Jira (Atlassian's project-tracking tool) is Turing-complete. Existing claims point vaguely at automation features without exhibiting a reduction. This article supplies a proof, with setup instructions and execution trace.

Mapping the Computational Model

A Minsky register machine needs only two unbounded counters and a finite set of labeled instructions:

• INC r; goto S
• DEC r; if r == 0 goto S else goto S'

Or, in plain English:

• increment register R, then goto some state S
• decrement register R, if R == 0 goto zero-state S, else goto nonzero-state S'

A Minsky program that adds register A into register B looks like:

1. DEC A; if A == 0 goto 3 else goto 2
2. INC B; goto 1
3. HALT

Minsky proved this model Turing-complete (1967). Exhibiting it in Jira's automation language therefore establishes the reduction. Here is how the model maps onto Jira:

The Epic's status encodes the current instruction. Automation rules inspect the linked-issue counts and decide the next status. INC and DEC are implemented as issue creation and deletion on the appropriate linked-issue type. Conditional branching is implemented as a JQL-conditioned rule.

Implementing Addition

Here is a minimal working implementation using one Epic, five linked issues, and one Automation rule per instruction state (Space Settings > Automation).

1. Create Workflow

Create a Jira Workflow with statuses initial state BACKLOG, then TODO, DEV and PROD. Any state can transition to any other.

Create an Epic in status BACKLOG.

2. Create Rule for TODO

DEC A; if A=0 halt, else goto DEV.

• Trigger: Epic status changed to TODO.
• If at least one linked Bug exists: delete one Bug, transition Epic to DEV.
• Else: transition Epic to PROD (halt).

3. Create Rule for DEV

INC B; goto TODO.

• Trigger: Epic status changed to DEV.
• Create a new Task, link it to the Epic.
• Transition Epic to TODO.

Both rules have "Allow rule to trigger other rules" enabled.

The screenshot below shows the two rules wired into the Epic's workflow.

4. Init Registers

Link 2 Bugs (A=2) and 3 Tasks (B=3) to the Epic.

5. Bootstrap the Machine.

Transition the Epic to TODO to start the cascade. Five transitions:

(2,3) TODO → 
(1,3) DEV  → 
(1,4) TODO → 
(0,4) DEV  → 
(0,5) TODO → 
(0,5) PROD

Recorded on a real *.atlassian.net instance.

The Epic lands in PROD with 0 Bugs and 5 Tasks linked. We've just added 2 + 3 = 5.

Fibonacci in Three States

The reduction above suffices to prove Turing-completeness. In addition to that, Jira's automation language can simplify Minsky operations. Convert Issue Type changes an issue's type instantly: Bug → Story, Story → Task, and so on.

CONVERT is expressible as DEC + INC. It doesn't extend Jira's computational power, but it shrinks the dispatch table dramatically for any move-loop, making non-trivial programs tractable.

Fibonacci as (A, B) → (B, A+B) collapses to three states with three registers (A=Bug, B=Task, C=Story), using TODO, QA (add it to the workflow), and DEV as the three instruction states:

TODO:
    if any linked Task exists:
        CONVERT Task → Story
        INC Bug
        transition to TODO
    else:
        transition to QA

QA:
    if any linked Bug exists:
        CONVERT Bug → Task
        transition to QA
    else:
        transition to DEV

DEV:
    if any linked Story exists:
        CONVERT Story → Bug
        transition to DEV
    else:
        transition to TODO

Initial state A=1, B=1, C=0. The sequence 1, 1, 2, 3, 5, 8, 13, … appears in B (Task count).

Unlike the addition machine, the Fibonacci machine has no halt state. It runs until Jira Cloud's chain-depth cap of 10 triggers, at which point the operator re-triggers the Epic to continue. A single status edit restarts the cascade.

The reduction still holds, the human just supplies the next clock tick. Jira Data Center exposes the same as automation.rule.execution.timeout and related, configurable properties.

Conclusion

Jira's automation language can encode a two-counter machine given unbounded issue creation and rule execution. Every physical computer is finite, so Jira Cloud's finite quotas do not refute the construction. Under that standard convention, Jira is Turing-complete.

So, if complex Jira automations feel like programs, it is because they literally are.

Late July. New York City. A bedroom on the top floor of a four-story building in which I installed an air conditioner with several thousand too few BTUs. I barely know what a BTU is. The temperature that day reached into the upper 90s Fahrenheit, with humidity just short of actual water. The tiny weak air conditioner struggled to cool the room down while a few feet away I struggled to fall asleep. And yet I was unable to sleep without some sort of covering. In this case it was the barest edge of my lightest sheet, touching the smallest possible part of my torso.

Why this compulsion to be covered, however minimally, in order to sleep?

Blankets are common, but not universal, to humans during sleep, at least in the modern day. But historically, the effort involved in weaving large sheets put blankets at much too high a price point for most to afford. From the linen bedsheets of Egypt around 3500 B.C. to wool sheets during the Roman empire straight through to cotton in medieval Europe, bed coverings were for the wealthy.

By the Early Modern period in Europe, which followed the Middle Ages, production had increased enough so that more middle-class people could afford bedding, though not easily. “The bed, throughout Western Europe at this time, was the most expensive item in the house,” says Roger Ekirch, a historian at Virginia Tech who has written extensively about sleep. “It was the first major item that a newly married couple, if they had the wherewithal, would invest in.” The bed and bedding could make up about a third of the total value of an entire household’s possessions, which explains why bedsheets frequently showed up in wills.

Sign up for the Atlas Obscura Daily Newsletter

A daily dose of hidden gems to visit, extraordinary places to eat and wondrous stories from around the world.

Your newsletter subscriptions with us are subject to Atlas Obscura's Privacy Policy and Terms and Conditions.

In place of blankets and sheets, other sources of heat were common at night, usually from multiple people sharing a bed, or often livestock.

Today, there’s minimal anthropological work about bedding around the world. The best is a 2002 paper by Carol Worthman and Melissa Melby of Emory University, who compiled a study of sleeping arrangements in different parts of the world. “Recognition of the paucity of anthropological work on sleep is galvanizing: a significant domain of human behavior that claims a third of daily life remains largely overlooked by a discipline dedicated to the holistic study of the human condition,” they wrote. This passes for outrage in an academic paper.

The paper looked into some foraging and non-foraging peoples who live in hot climates near the equator, and found that only the nomadic foragers regularly sleep without bed coverings. Everyone else uses some form of covering, whether that’s plant matter or woven fabric, even in central Africa and Papua New Guinea, both tropical climates. Much more common than sheets or blankets are some form of padding; basically nobody sleeps simply on the ground as a matter of course.

As one more example of the goodness of blankets, there has also been a decent amount of research about the calming effect of weighted blankets, which can weigh up to 30 pounds. Studies indicate that they can curb anxiety and even be used in the treatment of autism.

“The requirement for blankets takes on two components to it,” says Dr. Alice Hoagland, the director of the insomnia clinic at the Unity Sleep Disorder Center in Rochester, New York. “There’s a behavioral component and a physiological component.” The latter is a little more clear-cut, so let’s dive into that first.

About 60 to 90 minutes before a usual bedtime, the body starts losing core temperature. There’s a physiological explanation for that: when the body is heated, we feel more alert. And conversely, when the body cools down, we tend to feel sleepier. Cooler internal body temperatures are correlated with a rise in melatonin, a hormone that induces sleepiness. A bunch of doctors tested this out by making people wear skinsuits—they kind of look like cycling outfits—that dropped their body temperature just a touch, one or two degrees Fahrenheit, to see if they’d sleep better. They did.

Your body’s ability to regulate its own heat gets way more complicated than that at night, though. Say you sleep for eight hours each night. In the first four hours, plus the hour or so before you fall asleep, your body temperature will drop a bit, from around 98 degrees Fahrenheit to around 96 or 97. But the second four hours are marked by periods of rapid eye movement (REM) sleep, a phenomenon in which most of our dreams take place, along with a host of physical changes.

One of those physical changes is an inability to thermoregulate. “You almost revert to a more, and this is my word, reptilian form of thermoregulation,” says Hoagland. She says “reptilian” because reptiles are unable to regulate their own body temperature the way we mammals can; instead of sweating and shivering, reptiles have to adjust their temperature through external means, like moving into the sun or into cooler shadows. And for those brief periods of REM sleep, we all turn into lizards.

Even in perpetually hot climates, nighttime temperatures drop, and the night is coldest, coincidentally, right at the time when our bodies are freaking out and unable to adjust to it. (The night is coldest right after dawn, in direct contradiction to aphorism.) So, like lizards, we have to have some way to externally regulate our body temperatures. You may think it’s unnecessary to use a blanket at 10 p.m., when it’s still hot, but by 4 a.m., when it’s colder and you’re unable to shiver? You might need it. So we may know from past experience that we’ll thank ourselves later for having a blanket, and thus force ourselves to use one (or at least have one nearby) when going to bed.

There’s more to it than that, though. Another strange thing that happens in the REM periods of sleep is that our bodies drastically lower their levels of serotonin, the neurotransmitter most associated with feelings of calm, happiness, and well-being. You know what’s associated with higher levels of serotonin? Blankets. Various studies have indicated that sleeping with a weighted blanket can trigger an uptick in the brain’s production of serotonin. So yet again, the blanket might be filling a need that our REM-addled brains create.

The other element that might explain our need for blankets is what Hoagland refers to as “pure conditioning.” “Chances are you were raised to always have a blanket on you when you went to sleep,” she says. “So that’s a version of a transitional object, in sort of Pavlovian way.” Basically, our parents always gave us blankets to sleep with—babies are a bit worse than adults at thermoregulation, meaning they get cold easily, meaning well-meaning adults put blankets on them—and so getting under a sheet or blanket is associated with the process of falling asleep. Instead of Pavlov’s dogs drooling at the sound of a bell, we get sleepy when covered with a sheet.

If you Google around for this question, you’ll end up with a bunch of theories about blankets simulating the warm, enclosed feeling we had in the womb. There could be some element of theoretical protection or security imbued by the blanket, which might be another bit of conditioning, but Hoagland thinks the womb comparison is pretty unlikely. “I’m very suspicious of anyone who implies that this goes back to the feeling of being in the womb,” she says. “I think that’s very far-fetched.”

Another possible reason is that blankets are soft and feel good. I could not find any studies that examine the question of whether people like blankets because they’re soft and feel good, so this may remain a great unanswered question.