Hasan Akalp — Writing

Ten Hours, One Click, Almost Gone: Obsidian Plugin, iCloud Recovery, and a Small Lesson

Sat, 20 Dec 2025 00:41:00 GMT

TL;DR

Last week I was writing an Obsidian plugin. After about ten hours of work, I was close to a version I could actually use.

Then a small distraction turned into a big problem.

In a few seconds, my plugin folder disappeared. No drama, no complex bug — just a couple of quick clicks made while my brain was in “fix it fast” mode.

This is the story of what happened, how iCloud Data Recovery saved me, and why I changed my workflow right after.

What I was building

I’ve been using Obsidian for a long time. Besides regular note-taking, I also track a personal metric related to health and breathing quality.

My idea was:

Store daily metric values inside daily notes, in the frontmatter
Run periodic analysis and generate simple recommendations
Draw a custom Bases view that fits my workflow better than a generic table

So I started building a plugin around this. I kept it private, because it’s personal, and I don’t want to over-polish it or publish it yet. But technically, it was already “real”: TypeScript, a build pipeline, and a working prototype.

And then I made a change that triggered everything.

Why it went wrong

In Obsidian plugins, manifest.json is not just a random config file. It’s part of how Obsidian identifies and loads a plugin.

During quick experiments, I changed the plugin name in manifest.json.

When I went back to Obsidian, my plugin appeared twice. At that moment I assumed it was just a temporary state problem — something like “Obsidian UI got confused” while I was iterating quickly.

So I did what many of us do when we see duplicate entries: I clicked Delete on one of them.

That was the real mistake.

Because I was following the Developer Docs–style setup, my whole development codebase lived inside the vault under .obsidian/plugins/.... So deleting “the plugin” was not just uninstalling a build artifact. It removed the actual source folder.

I commit often, but I hadn’t pushed yet.¹

So it felt like watching ten hours fly away.

The recovery moment: iCloud.com Data Recovery

First, I checked the Trash. Nothing.

Then I checked iCloud “Recently Deleted”. Still nothing.

I was stressed and moving fast, clicking around iCloud.com with that mix of panic and anger — and I randomly found a section called Data Recovery.

It showed a message like “thousands of recoverable files”. I opened it, and I saw entries marked as deleted just minutes ago.

That was it. My files were there.

But there was another problem: the list wasn’t just my plugin code.

Because my plugin folder also contained node_modules and .git, the recovery list was huge. Thousands of files. And I only cared about maybe 5–10 real artifacts.

The semi-technical trick: scripting a virtualized list

I decided to speed things up with a small script in Safari DevTools.

My first plan was full automation: detect the items under my plugin path and auto-select them. But it didn’t work reliably.

The reason is how Apple built that recovery UI: it looks like a long list, but it’s not actually rendering thousands of DOM nodes at the same time. It uses a common performance pattern called list virtualization.²

In short:

The modal only keeps a small set of rows in the DOM
When you scroll, the UI reuses the same row elements
The “path text” and other values update dynamically inside those reused nodes

So a script that “selects everything matching X” can fail because the element you marked might later represent a totally different file after scrolling.

Once I realized this, I changed the approach.

Instead of trying to select items programmatically, I turned the script into a visual helper:

Files under my target prefix got a green border
Everything else got a red border

Then I manually scrolled through the list and checked only the green ones. It wasn’t perfect, but it was stable. After 15–20 minutes of scrolling and selecting, I restored the files.

And the code was back (without the heavy folders, which I didn’t need anyway).

What I changed immediately

After recovery, I didn’t continue development. First, I fixed the workflow.

I moved the project out of the vault into my normal workspace and treated the vault as a runtime target, not a source of truth.

I also added a packaging flow so only the small output set ends up in the vault.

My scripts ended up like this:

"scripts": {
  "build": "tsc -noEmit -skipLibCheck && node esbuild.config.mjs production",
  "build:dev": "tsc -noEmit -skipLibCheck && node esbuild.config.mjs development",
  "package": "npm run package:prod",
  "package:prod": "npm run build && node package-plugin.mjs",
  "package:dev": "npm run build:dev && node package-plugin.mjs"
}

And the packaging script basically copies only what matters:

import { promises as fs } from "fs";
import path from "path";
import { fileURLToPath } from "url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

async function ensureDir(dir) {
  await fs.mkdir(dir, { recursive: true });
}

async function removeDir(dir) {
  await fs.rm(dir, { recursive: true, force: true });
}

async function fileExists(filePath) {
  try {
    await fs.access(filePath);
    return true;
  } catch {
    return false;
  }
}

async function copyFile(source, destination) {
  await fs.copyFile(source, destination);
}

async function main() {
  const manifestPath = path.join(__dirname, "manifest.json");
  const manifest = JSON.parse(await fs.readFile(manifestPath, "utf8"));
  const pluginId = manifest.id;

  if (!pluginId || typeof pluginId !== "string") {
    throw new Error("Unable to determine plugin id from manifest.json");
  }

  const releaseRoot = path.join(__dirname, "release");
  const outputDir = path.join(releaseRoot, pluginId);

  await removeDir(outputDir);
  await ensureDir(outputDir);

  const artifacts = [
    { file: "manifest.json", required: true },
    { file: "main.js", required: true },
    { file: "styles.css", required: false },
  ];

  for (const artifact of artifacts) {
    const source = path.join(__dirname, artifact.file);
    if (!(await fileExists(source))) {
      if (artifact.required) {
        throw new Error(
          `Missing required artifact: ${artifact.file}. Did you run npm run build?`
        );
      }
      continue;
    }

    const destination = path.join(outputDir, artifact.file);
    await copyFile(source, destination);
  }

  console.log(`Plugin packaged at ${path.relative(__dirname, outputDir)}`);
  console.log(
    "Copy this folder into <vault>/.obsidian/plugins to test the build."
  );
}

main().catch((error) => {
  console.error(error);
  process.exit(1);
});

Then I just moved the packaged folder into the vault to test it:

mv release/<plugin_name> <vault>/.obsidian/plugins/

And yes — I pushed everything immediately after that.³

Conclusion

This whole story was not about a hard technical problem.

It was about how a small distraction can have a heavy cost, especially when your development setup makes it easy to delete the wrong thing.

I’ll keep the plugin private for now. It’s a personal project and I don’t want to turn it into a “public product” yet.

But the lesson is already public in my head:

Even if you’re careful, “just one quick click” can be enough. So don’t let your development flow depend on luck.

the most expensive “later” I’ve ever said. ↩
the same trick that keeps long feeds fast. great for users, terrible for my script. ↩
even when I forget, my agents don’t :) ↩

SlidePlay: A Local Quiz App for the Living Room

Sun, 30 Nov 2025 17:40:00 GMT

TL;DR

GitHub repo: akalp/SlidePlay

SlidePlay is a small web app I built as a birthday surprise for my dad. It runs only on a local network and turns a TV plus a few phones into a private quiz game.

Built with Node.js, Express, and Socket.IO.
Uses three roles: Player, Host, and Admin, all running in the browser.
All content comes from a single slides.json file, so new events are mostly “edit JSON, restart, play”.
Supports content, question, scoreboard, video, and final slides.
Adds a scoring model based on correctness + speed bonus.
Implements remote video control from the admin view (play / pause / mute / seek / restart).
Uses chokidar to watch slides.json and avatar assets, so changes appear without restarting.
In practice it feels like “a private Kahoot meets Google Slides, served from my laptop over Wi-Fi.”

The rest of this post is about why I built it, what it does, and how it works under the hood.

Why I built my own tiny quiz app

I built SlidePlay because I wanted my dad’s birthday to feel a bit more interactive than “let’s click through a slideshow”.

I had a few constraints in mind:

We’d be in the living room, with a TV, a laptop, and a bunch of phones/tablets.
I wanted people to join from their own devices, with their own names and avatars.
I wanted a mix of photos, short videos, and quiz questions about him.
I didn’t want to depend on an external site or account — just run it on my machine over the home Wi-Fi.

There are plenty of existing quiz tools, but they often assume:

Classrooms or big events.
Cloud accounts and public links.
A generic brand/theme that doesn’t feel personal.

For a small family evening, that felt wrong. I wanted a mini game show that lived entirely on my laptop and on our TV.

So SlidePlay started as a one-off birthday surprise that I could also reuse for future family or friend events.

What SlidePlay is

At a high level, SlidePlay is a real-time slideshow and quiz system:

A Node.js server runs on my laptop and listens on the local network.
A Host view runs on the TV (or any big screen) and shows slides, questions, and scoreboards.
An Admin view runs on my laptop and lets me control the flow: next/previous slide, reveal answers, jump to a specific slide, control video playback, reload slides.
Player views run on phones and tablets; everyone joins with a name and avatar and answers questions from there.

All three views are standard web pages, and I keep them in sync using Socket.IO.

In my head, the pitch is:

A small, self-hosted “Kahoot + Google Slides” hybrid that only lives on your Wi-Fi.

I don’t use a database or any external service. All state lives in memory for the duration of the session, and all content comes from a single JSON file.

How it works under the hood

Express + Socket.IO as the real-time backbone

The backend is a single Node.js process:

Express serves static files from public/.
Socket.IO handles live events between players, host, and admin.

On each new Socket.IO connection, I:

Send down the current state (slides, settings, current slide, players).
Listen for admin commands (next slide, previous slide, goto, reveal, video control).
Listen for player events (join, answer).
Broadcast updates to everyone (player list, slide changes, results, scoreboards).

In simplified pseudo-code, the main socket wiring looks like this:

io.on("connection", (socket) => {
  // Initial state for a new client
  socket.on("getState", () => {
    socket.emit("state", {
      slides,
      settings,
      currentSlideId,
      players,
    });
  });

  // Player joins
  socket.on("join", ({ name, avatar }) => {
    players[socket.id] = { name, avatar, score: 0 };
    io.emit("playersUpdated", players);
  });

  // Player answers a question
  socket.on("answer", ({ slideId, choiceIndex }) => {
    handleAnswer({ socketId: socket.id, slideId, choiceIndex });
  });

  // Admin controls
  socket.on("admin:next", () => goToNextSlide());
  socket.on("admin:prev", () => goToPreviousSlide());
  socket.on("admin:goto", (slideId) => goToSlide(slideId));
  socket.on("admin:reveal", () => revealCurrentAnswer());

  // Clean up on disconnect
  socket.on("disconnect", () => {
    delete players[socket.id];
    io.emit("playersUpdated", players);
  });
});

server.js keeps in-memory state for:

Loaded slides and settings.
The current slide ID.
The list of players and scores.
The active question state (who has answered, who is still pending).

Slides as data: `slides.json`

I didn’t want to rebuild the app for every event. Instead, I treat slides as pure data.

All content is defined in public/slides.json. At the top, there is a settings object for game behavior. Then there is a slides array of slide objects.

A simplified version looks like this:

{
  "settings": {
    "pointsPerCorrect": 100,
    "maxSpeedBonus": 50,
    "speedBonusWindowSec": 10,
    "revealDelayMs": 3000,
    "autoAdvanceAfterReveal": false
  },
  "slides": [
    {
      "id": 1,
      "type": "content",
      "title": "Welcome",
      "text": "Happy Birthday!"
    },
    {
      "id": 2,
      "type": "video",
      "title": "Memory Lane",
      "video": "assets/video.mp4"
    },
    {
      "id": 3,
      "type": "question",
      "title": "Favourite dessert?",
      "choices": ["Option A", "Option B", "Option C"],
      "answerIndex": 1
    },
    {
      "id": 4,
      "type": "scoreboard",
      "title": "Scores so far"
    },
    {
      "id": 5,
      "type": "final",
      "title": "Thanks for playing",
      "text": "🎉"
    }
  ]
}

The supported slide types are:

content – basic text/image slides.
video – video slides that I can remote-control from the admin page.
question – multiple choice questions with a single correct answer.
scoreboard – a sorted list of players and scores.
final – a closing slide at the end.

To build a new event, I usually just:

Replace images and videos in public/assets/.
Edit public/slides.json to match the new story.
Run npm start and open the URL on the TV and phones.

I don’t have to touch JavaScript for normal content changes.

Scoring: correctness + speed bonus

I wanted the game to feel like a quiz show, not just a static poll. SlidePlay keeps a score for each player and uses a simple model:

When a question starts, I snapshot which players are currently connected.
Each of those players can answer once.
A correct answer gets base points plus a speed bonus.¹
A wrong answer gives zero points.
When everyone in that snapshot has answered (or disconnected), the server reveals the answer.

The core scoring function is roughly:

function gradeAnswer(slide, choiceIndex, elapsedMs) {
  const correct = choiceIndex === slide.answerIndex;
  if (!correct) return { correct: false, delta: 0 };

  let delta = settings.pointsPerCorrect;

  const windowMs = settings.speedBonusWindowSec * 1000;
  const clamped = Math.max(0, Math.min(windowMs, elapsedMs));
  const bonusRatio = 1 - clamped / windowMs;
  const bonus = Math.round(bonusRatio * settings.maxSpeedBonus);

  delta += bonus;
  return { correct: true, delta };
}

When a question is done, I:

Reveal the correct answer on the host and player screens.
Update scores and broadcast them.
Optionally auto-advance to the next slide after revealDelayMs.

It’s not a complex system, but it’s enough to create some friendly competition.

Three browser roles: Player, Host, Admin

SlidePlay splits the UI into three separate pages with different responsibilities.

Player (phones and tablets)

The player view (/) is what everyone uses on their phones:

Join with a name and avatar.
See the current slide in a simple layout.
For questions, tap one of the answer buttons.
After reveal, see whether the answer was correct and how many points they got.

Host (TV or projector)

The host view (/host.html) is what I put on the TV:

Show the current slide in a large, clean format.
For questions, highlight the correct choice after reveal and list who answered what (with timing).
For scoreboard slides, show a sorted list of players and scores.

This is the “stage” view everyone in the room watches.

Admin (laptop, tablet or phone)

The admin view (/admin.html) is my control panel:

Buttons for Previous, Next, and Goto slide.
A Force Reveal button to reveal early.
A Reload JSON button to re-read slides.json.
Remote video controls (Play, Pause, Restart, Mute/Unmute, Seek).
A small live scoreboard panel.

Under the hood, all three views are basic Socket.IO clients listening to a subset of events they care about.

Remote video control

I wanted to mix in short videos (old clips, fun moments) without losing control from the admin panel.

For video slides, I treat the admin as a remote control for the host:

// Admin asks to control the video
socket.emit("admin:videoControl", { action: "play" });

// Server forwards to host clients
socket.on("admin:videoControl", (payload) => {
  if (!isValid(payload)) return;
  io.to("host").emit("host:videoControl", payload);
});

// Host applies the action
socket.on("host:videoControl", ({ action, time }) => {
  const video = document.getElementById("hostVideo");
  if (!video) return;

  switch (action) {
    case "play":
      video.play();
      break;
    case "pause":
      video.pause();
      break;
    case "restart":
      video.currentTime = 0;
      video.play();
      break;
    case "mute":
      video.muted = true;
      break;
    case "unmute":
      video.muted = false;
      break;
    case "seek":
      video.currentTime = time;
      break;
  }
});

On the player view, I only show the text for the video slide. The actual playback happens on the host screen, which keeps everyone focused on the TV.

A small practical note here: Chrome’s autoplay rules matter. Muted autoplay is usually fine, but autoplay with sound is only allowed after the user has interacted with the site (click, tap, etc.), or if Chrome considers the user “engaged” with that domain, or the site is installed as a PWA In other words, if I try to call video.play() from a Socket.IO event before anyone has clicked anything on the host page, Chrome may silently block it. In practice I either start videos muted, or I require at least one manual click on the host view before I rely on remote play commands.

Avatars and live reload with `chokidar`

For joining, I wanted something more fun than plain text names, so I added avatars.

Avatars are just images in public/assets/avatars/. On startup, the server scans that directory and builds a list of available avatar URLs. Players see this list and tap one to choose it.

To avoid restarts while tweaking the event, I also wired in chokidar:

chokidar.watch("public/slides.json").on("change", () => {
  loadSlidesFromDisk();
  io.emit("slidesReloaded", { slides, settings });
});

if (fs.existsSync(AVATAR_DIR)) {
  chokidar
    .watch(AVATAR_DIR, { ignoreInitial: true })
    .on("add", loadAvatars)
    .on("unlink", loadAvatars);
}

This gives me:

Live slide reload when I edit slides.json.
Live avatar updates when I add/remove avatar images.

For a real event, this is great: I can fix typos, tweak wording, or swap an image a few minutes before we start, without touching the Node.js process.

The first living-room test

The first real test was on my home network:

I ran the Node.js server on my laptop.
I opened the host view in a browser and mirrored it to the TV.
Five people joined as players from phones and a tablet over Wi-Fi.

The funniest bug was not in my code but in the browser: I shared the local URL, people tapped it, and Chrome tried to be “smart” and turned it into https://.... Of course, my small Node server was only listening on plain http://, so nothing worked at first.²

Once we realized what was going on and everyone typed the http:// URL manually, everything clicked:

Players picked avatars and names.
I walked through content, video, question, scoreboard, and final slides from the admin panel.
Scores updated in real time, and the scoreboard slides made the quiz feel real.
Most importantly, my dad got a custom, interactive birthday quiz built around his own story.³

All of it stayed on the local network. No public link, no external service, no uploads.

Closing thoughts

SlidePlay is not a product I plan to ship. It’s a small template that does one thing well:

Turn a TV and a few phones into a private quiz show that lives entirely on your laptop.

From a technical side, the interesting parts for me were:

Using Express + Socket.IO as a simple real-time backbone.
Treating slides as data in slides.json, not hard-coded components.
Implementing a small but satisfying scoring system (correctness + speed).
Splitting the UI into Player / Host / Admin roles.
Adding remote video control and live reload with chokidar.

If you’ve ever wanted a private “Kahoot meets Google Slides” for your own family, friends, or a small team, this pattern works well: keep everything local, keep the content in one JSON file, and use WebSockets to glue a few simple web pages into something that feels like a live show in your living room.

the speed bonus made everyone very competitive, very fast. ↩
next time: a QR code with the full http:// URL on the TV. ↩
the night he understood my job best, and he was really happy. ↩

My First Oh-My-Zsh Plugin: caff

Wed, 26 Nov 2025 18:00:00 GMT

TL;DR

GitHub repo: akalp/caff

As developers we constantly run long builds, tests, containers and AI-assisted workflows that easily outlive macOS’s default sleep behavior.
Amphetamine is convenient from the menu bar, but especially in clamshell mode its sessions can end abruptly and push the machine toward sleep at awkward moments.
caffeinate is scriptable and process-scoped, but you have to remember flag combos like -disu, think in raw seconds via -t <seconds>, and it gives you no visual feedback.
caff is my first Oh My Zsh plugin that wraps caffeinate with nicer ergonomics: caff disu 2h -- npm test, duration presets (short / medium / long / night), human-friendly units (2h, 30m), an inline countdown or spinner, quiet mode, and clean exit-code propagation.

For years I treated "keeping my Mac awake" as an annoying detail I only thought about when something broke:

A long test suite died halfway through because the machine went to sleep.
A big Docker image build got interrupted.
An AI-assisted refactor or multi-agent workflow was still running when I left the desk — and silently paused when the screen turned off.

If you do any kind of serious development on macOS, there's a good chance you've run into the same thing: you start a long-running task, step away for a bit, and come back to discover that sleep won the race.

This blog post is about how I tried to solve that with Amphetamine, why that wasn't quite enough for my setup (especially in clamshell mode¹), and how that annoyance pushed me to write my first Oh My Zsh plugin: caff, a smarter wrapper around macOS' built‑in caffeinate command.

Why a developer needs to keep the machine awake

Modern development is full of tasks that take longer than a coffee break:

Long builds
- Frontend bundles in complex monorepos
- Native iOS/Android builds
- CI-like local scripts that run multiple steps
Heavy test runs
- Full integration or end-to-end test suites
- Load tests or benchmarks
Dev tooling and environments
- Docker image builds and multi-container setups
- Local Kubernetes clusters
- Database migrations and seed scripts
AI-assisted workflows
- Long-running codegen or refactor jobs
- Background documentation generation
- Multi-agent systems orchestrating many small steps

The pattern is the same: you run something that might take 10, 30, 60+ minutes. You don't want to sit and wiggle the mouse every five minutes to keep the Mac awake. You probably want to:

Kick off the task
Maybe glance at logs
Walk away, grab coffee, do something else
Come back to a finished job — not a half-baked one paused in sleep

On top of that, if you're using AI tooling heavily, you might:

Trigger a long refactor on a large codebase
Ask an agent to generate many tests or docs
Let a script iterate over files and call an API many times

In those scenarios, you might not be actively typing the whole time. The system sees "no input" and assumes it's safe to sleep, even though a lot of important work is still in progress.

So we need something that tells macOS: "Stay awake intentionally while I'm doing this, then go back to normal."

Amphetamine and `caffeinate`: the usual suspects

On macOS, there are two main approaches people use:

Amphetamine

Amphetamine is a popular macOS app for preventing sleep. It gives you:

A nice menu bar UI
Presets like "stay awake for X hours" or "while this app is running"
Quick toggles without touching the terminal

For many users, that's more than enough. Click, pick a duration, done.

`caffeinate`

Under the hood, macOS also ships a CLI tool:

caffeinate [options] [command]

This utility can:

Prevent display, idle, system sleep, or combinations
Run for a fixed duration via -t <seconds>
Stay awake while a specific command is running

For example:

# Prevent system sleep for 1 hour
caffeinate -t 3600

# Prevent display + idle sleep while running tests
caffeinate -d -i -- npm test

It’s powerful and scriptable — but the UX is… very raw:

You have to remember flag combinations (-d -i -s -u etc.)
Durations must be in seconds
No visual feedback or countdown
No handy presets like "short", "long", or "overnight"

Still, as a developer living in the terminal, caffeinate feels like the right primitive to build on.

The Amphetamine + clamshell problem

For a while, I used Amphetamine as my main sleep blocker. It mostly worked — until I combined it with clamshell mode.

My setup looks roughly like this:

MacBook Pro in clamshell
External monitor(s)
External keyboard + mouse

In that setup, Amphetamine sessions behave a bit differently:

You start a timed session, e.g. 2 hours.
You close the lid, work on the external display, everything is fine.
When the timer ends or you manually stop the session, macOS immediately goes back to its default sleep behavior.

The annoying part: in clamshell mode, that usually means:

The external screen goes dark and the machine basically wants to sleep right now.

This leads to a couple of UX problems:

If you end an Amphetamine session (or it expires) while still in clamshell, you can be kicked out of what you were doing.
If you forget the session is about to end, you might lose context or ongoing work on the external display.
Managing sessions starts to feel brittle: "Will my Mac instantly go to sleep if I hit stop?" is not a good mental model while you're in the middle of a task.

For short tasks this is tolerable. But when you're constantly running builds, tests, and AI-assisted workflows, you don't want the sleep policy to surprise you.

I wanted something more predictable and more terminal-native.

Why `caffeinate` is a better fit for my workflow

caffeinate has a few built-in advantages if you live in the shell:

Process-scoped sessions You can say "stay awake exactly as long as this command runs":
```
caffeinate -d -i -- npm run build
```
When the build is done, the process exits and the system returns to normal. There's no separate "session" to remember to stop.
Scriptability You can bake it into:
- Shell aliases and functions
- Project scripts (package.json, Makefiles, etc.)
- CI-like local runners
Fine-grained control You can choose exactly which sleep sources to block:
- -d — display sleep
- -i — idle sleep
- -s — system sleep
- -u — declare user is active
Works well with clamshell mode When used with the right flags and/or durations, caffeinate is just another process. It doesn't care whether the lid is open or closed — if it's running, it will keep the system awake according to the flags you gave it.

In other words, caffeinate behaves like a tool you can compose with other tools. It feels like a better foundation for a dev-centric workflow than a mouse-driven menu bar app.

The only issue: its ergonomics are not great. Even though you can pack flags as -disu, it still expects raw seconds via -t <seconds> and gives you no visual feedback.

I don't want to think in seconds.
I'd like some quick presets like short, medium, long, night.
I'd like a simple visual indication when I'm in "awake mode".

So I did what any annoyed developer would do: I wrote a wrapper.²

Introducing `caff`: a smart `caffeinate` wrapper

caff is my first Oh My Zsh plugin — a small Zsh function that turns caffeinate into something I actually enjoy using.

At a high level, it gives you:

Shorthand flags using disu syntax
Human-friendly durations like 2h, 30m
Named presets (short, medium, long, night/overnight)
Optional command execution via --
An interactive countdown bar or spinner
Start/finish messages, quiet mode, and proper exit codes

A nicer mental model

Instead of this:

# Using caffeinate directly
# (flags must include a leading dash, duration is in seconds)
caffeinate -disu -t 7200 -- npm run build

I can now write:

caff disu 2h -- npm run build

Where:

disu → -d -i -s -u
2h → -t 7200

The plugin also defines a short alias, so this works too:

cf disu 2h -- npm run build

Human durations and presets

caff understands:

2h → 2 hours
30m → 30 minutes
t=3600 → raw seconds, like -t 3600

Plus named presets:

short → 15 minutes
medium → 1 hour
long → 3 hours
night / overnight → 8 hours

So common patterns become very readable:

# Short session while you grab a coffee
caff di short

# Keep the machine fully awake for the next 3 hours
caff disu long

# Overnight job with tests
caff disu night -- yarn test:e2e

Command or no command

caff adjusts its behavior depending on whether you pass a command after --.

With a command

caff disu 1h -- npm test

Runs caffeinate + npm test together
Prints a start message with flags and duration
No interactive UI
When npm test finishes, caff exits with the same status code

This makes it safe to use in scripts and automations.

Without a command

# Duration known → countdown bar
caff disu 45m

# Duration unknown → spinner
caff disu

Known duration: caff starts caffeinate in the background and shows a single-line progress bar with remaining time.
Unknown duration: it shows a little spinner that keeps animating until you hit Ctrl+C.

In both cases, Ctrl+C stops the UI and caffeinate, and caff exits with status 130.³ That makes it explicit that the session was interrupted.

Quiet mode for scripts

Sometimes you want zero noise — especially in scripts or logs. For that, there's a quiet mode:

caff --quiet disu long -- ./deploy.sh

or equivalently:

caff -q disu long -- ./deploy.sh

No UI
No start/finish messages
Same exit-code propagation behavior

Why this helps my clamshell workflow

In clamshell mode, my usage now looks like this:

For a long-running command:
```
cf disu medium -- pnpm lint && pnpm test
```
- External monitor stays awake while the command runs.
- When it finishes, caff exits, the system goes back to normal.
- No surprise sleep in the middle of a task.
For a "manual" session:
```
cf disu night
```
- I get a countdown for 8 hours.
- If I’m done earlier, I hit Ctrl+C.
- If I forget, it ends after the preset duration and the system behaves normally again.

It's predictable, scriptable, and — most importantly — lives where I already spend my time: in the terminal.

Closing thoughts

Writing caff started as a tiny quality-of-life improvement: "I just want a nicer way to use caffeinate." But it ended up being my:

First Oh My Zsh plugin
First little experiment in “turn an annoyance into a tool”
A reminder that many dev problems are solvable with a thin layer of ergonomics on top of existing primitives

If you:

Work in clamshell mode
Run long builds/tests/AI tasks
Live in the terminal

…then caffeinate is probably already the right tool for you. caff just makes it nicer.

lid closed, external monitor, keyboard on the desk. ↩
even the name felt long. I went with caff, that felt long too, so I added a cf alias. ↩
128 + SIGINT (2). scripts can tell “interrupted” from “failed”. ↩

Yatay geçiş mi? O da ne?

Sun, 26 Dec 2021 00:00:00 GMT

Evet üniversitedesin ama o da ne...

Burası hiç de senin beklediğin gibi değil 😬 Bu dert değil, hala istediğin bölüm veya üniversite için bir şansın var: Yatay geçiş. Peki neyin nesi bu, nasıl yapılır ve ne zaman yapabilabilir? Hadi hepsini cevaplayalım 😇¹

Yatay Geçiş?

Yatay geçiş, üniversite sınav sonucuna veya not ortalamana göre üniversiteni, bölümünü veya her ikisini birden değiştirebildiğin bir uygulama aslında. Öğrenci için bir çıkış noktası diyebiliriz. Üniversiteden veya bölümden memnun kalmadıysan değiştirebilmen için bir yol. ✌🏻

Nasıl yapılır?

İki türlü geçiş var:

Kurumlar arası
Kurum içi

Ayrıca üst paragrafta belirttiğim gibi iki farklı şekilde geçiş yapılabiliyor:

Üniversite sınavı sonucuna göre
Genel not ortalana göre

Kurum içi

Burayı okuyorsan üniversite tam sana göre ama bölüm tercihin yanlış demektir. Üzülmeye gerek yok 😇 Mevcut bölümünle eşdeğer düzeydeki bir diploma programına eğer sınav puan türü de aynı ise üniversitenin yönetim kurulunun belirlediği kontejanlar dahilinde yatay geçiş yapabilirsin. Burada yönetim kurulu bazı şartlar koyabiliyor. Takip etmende fayda var 😉 Geçmek istediğin bölüm farklı puan türüne sahip ise ilgili puan türünde yaptığın üniversite puanının geçmek istediğin bölümün sınav senendeki puanına eşdeğer veya yüksek olması gerekiyor. Eğer şartı sağlıyorsan bekleme ve başvur 🏅

Kurumlar arası

"Bu üniversite de pek benlik değilmiş, değiştirebilir miyim acaba 🤔" dediğini duyar gibiyim. Elbette değiştirebilirsin. Burada önemli olan hedefin. Üniversite değiştirmek istiyorsan eğer hem genel ortalaman ile hem de üniversite puanın ile geçiş yapabilirsin. Yok ben bölüm de değiştireceğim diyorsan burada kötü bir haberim var, sadece üniversite puanını kullanabilirsin 😢

Üniversitem değişsin ama bölümüm aynı kalsın: Üniversite sınavındaki puanın, geçmek istediğin üniversitedeki bölümünün sınav senendeki puanına eşdeğer veya o puandan yüksekse direkt başvurabilirsin. Bu şekilde birçok arkadaşım üniversite değişikliği yaptı,² bu sayede bulunduğun üniversitede ortalama kasmak zorunda kalmıyorsun. Bir öğrenci bundan başka ne isteyebilir ki 😏

Eee, üniversite puanın üst paragraftaki şartı sağlamıyorsa ne olacak peki? 🤔 Burada cevap genel not ortalamanda saklı. Eğer genel not ortalaman geçmek istediğin üniversitenin belirlediği değere eşdeğerse veya puanın bu değerden yüksekse üzülme sen de başvurabilirsin 👑

Üniversite yetmez, bölümüm de değişsin: Burada genel not ortalaması çalışmıyor maalesef 🙁 Yukarıda bahsettiğim üniversite puanı yolu buradaki tek yol. Geçmek istediğin bölümün sınava girdiğin senedeki puanına denk veya o puandan daha fazlasına sahip olman lazım.

Ne zaman peki?

Henüz son iki sınıftan birinde değilsen ve birinci yılını tamamlamışsan şanslısın, bu uygulamadan faydalanabilirsin. 🥇

Peki başka ne şartlar var?

Eğer geçmek istediğin bölüm İngilizce ise şimdiki bölümünün de İngilizce olması gerekiyor ayrıca geçmek istediğin üniversite senden İngilizce sınav belgesi isteyecektir. Şimdiye kadar sadece İzmir Yüksek Teknoloji Enstitüsü'nün istemediğini duydum, onun dışında bildiğim tüm üniversiteler TOEFL gibi sınavların sonucunu istiyor ya da kendi İngilizce sınavlarından belli bir puanı almanı istiyor.

Ayrıca, dönem kaybının olmaması gerekiyor. Dönem kaybın varsa kabul alma şansın yoka yakın diyebiliriz. 🥲

Ee nasıl geçtiğimi anlayacağım?

Üniversitelerin belli bir yatay geçiş kontejanı oluyor. Sonuçları da bu kontejana göre açıkılıyorlar, yedeklerle birlikte. Eğer bu kontejana girebilirsen tebrikler, artık bölümünü ve/veya üniversiteni değiştirdin 🥇 Yedeklerdeysen de üzülme, asıl adaylar planlarını değiştirmiş ve/veya başka üniversiteden/bölümden kabul almış olabilirler, sakince bir sonraki duyuruyu takip et. 👀

Kontejana dahil olma şansını artırmak için genel not ortalamanı yüksek tutman gerektiğini dipnot olarak düşmek istiyorum. Bunun başka yolu yok maalesef ama idealler uğruna bunu göze almalıyız, değil mi? 😊

Önceki derslerime ne olacak?

Gittiğin yerde ortak dersler varsa bu derslerini sayacaklar zaten, rahat ol 🙂 Peki farklı olan dersler? Burada bir şart var. Eğer farklı olan ders eski üniversitende/bölümünde zorunlu ders ise seçmeli ders olarak saydırabiliyorsun ama eğer seçmeli bir ders ise maalesef bu dersi saydıramıyorsun. Üniversitenin bu konuda rahatlık sunuyorsa ona bir şey diyemem tabi 😊 Araştırmak lazım bunları hep 🤓

2021’de yazdım; şartlar değişmiş olabilir, başvurmadan önce güncel yönetmeliğe bak. ↩
ben de bu yoldan geçtim. ↩

Bilgisayar Mühendisliği Kazandım, Ne Yapmalıyım?

Thu, 23 Sep 2021 00:00:00 GMT

Bölümü kazanmak

Tebrikler! Zoru başardın ve üniversite kazandın 💪 Özellikle de istediğin bölümü kazanmanın verdiği haz gerçekten çok güzel. Tercih listemi hatırlıyorum da tamamen bilgisayar mühendisliği ve elektrik-elektronik mühendisliğinden oluşuyordu. Elektrik-elektronik mühendisliğini de çevremdeki bazı yazılımcıların bu bölümden mezun olmasından dolayı yazmıştım, tabii dönemimdeki popülaritesi de etkiliydi. Ama tam da istediğim gibi bilgisayar mühendisliğine yerleşmiştim. Peki bölüm tamam ama ya üniversite? Burada güzel bir haberim var, hala istediğin üniversiteye gitmek için şansın var. Ben de istediğim üniversiteyi kazanamamıştım fakat yatay geçiş yaparak istediğim üniversiteye gitmeye başladım. Yatay geçiş konusu ile ilgili yazımı da yakında paylaşacağım,¹ ara ara sosyal medya hesaplarımı ve burayı kontrol etmeyi unutma 😉

Kazandın, peki şimdi?

Kısaca bazı tavsiyelerde bulunacağım. Bir şeyler eklemek isteyenler veya yok arkadaş olmaz öyle iş diyecekler de benimle istedikleri gibi iletişime geçebilirler 😊

Hadi başlayalım 🤘

Bilgisayar. Hemen gidip en güçlü bilgisayarı almalısın (!). Tabii ki böyle bir şeye ihtiyacın yok! Genel yapılan yanlışlardan biri asla ihtiyacın olmayacak güçte bir bilgisayara sahip olmaya çalışmak. Günümüz Türkiye şartlarında bilgisayarlar genel olarak pahalı cihazlar² fakat olabildiğince fiyat/performans bir bilgisayar işini fazlasıyla görecektir.³ Eğer bir bilgisayara sahipsen de bekle ve üniversitedeki durumunu inceleyerek bu alımı gerçekleştir.
Yabancı dil. İngilizce alanımız için çok önemli. Eğer üniversitende hazırlık seçmeli ise mutlaka seç. Yabancı kaynaklar alanımızda vazgeçilmez. Tabii sadece hazırlık da yetmiyor, bolca içerik tüketmek İngilizce becerilerini geliştirmen için en gerekli şey.
Kariyer. Kariyerinde nasıl ilerlemek istediğine erken dönemde karar vermek faydalı olacaktır. Bu karar bölümdeki 4 senende yol haritanı çıkarmak için vazgeçilmez bir unsur. Eğer buna karar vermezsen son sınıfta veya 4 senenin sonunda "Eee şimdi ben ne yapacağım?" derken bulabilirsin kendini. Ayrıca erken davranmak daha sonra seçimini sorgulaman ve gerekirse değiştirebilmen için de sana vakit tanıyacak. Şimdi kariyer hedefi kısmını ikiye böleceğim:
1. Akademi. Akademik ilerleme konusu biraz karmaşık. Hangi alanda yapmak istediğin konusunda başlangıçta fikrin olmayabilir. Bu durumda 3. sınıfta alacağın teknik dersler seçim konusunda sana yardımcı olabilir. Ayrıca bu alanda ilerlemek istiyorsan notlarına oldukça dikkat etmen gerekiyor. Burada verebileceğim nacizane öneri alanını seçtikten sonra bölümünde o alanda çalışan hoca ile görüşmen ve mümkünse hocanın yanında lisans araştırmacısı olarak çalışmaya başlaman. Bu sana çok fazla şey kazandıracak emin olabilirsin. Hocan ile birlikte yapacağın akademik çalışmalar da yurt dışındaki üniversitelere açılan kapın olabilir 😉 Eee sonradan karar değiştirdin ne olacak? Hiçbir şey! Akademik olarak kazandığın bilgiler sektörde de işine yarayabilir. Akademik ilerlemek sektör bilgisi olarak geride kalmak değildir 🤘
2. Sektör. Bu durumda da tercih yapman gerekecek elbette. Seçebileceğin alan oldukça fazla. Şu an için aklıma gelenler: Backend, Frontend, Mobil, DevOps, Cyber Security, Gömülü Sistemler, Test, vb. Tam olarak neyden hoşlandığını elbette bilemezsin, bunun için biraz araştırmalısın. Bu alanlarda önde gelen kişileri takip edebilir ve İnternet alemindeki sayısız projeyi inceleyebilirsin. Peki alanımı seçtim, şimdilik, peki ya sonra? Basitten başlayarak proje üretimine başlayabilirsin, tabii bunları GitHub, GitLab, BitBucket gibi servislerde yayınlamayı da unutma. Bunlar senin en büyük referansların olacak.⁴ Bir diğer önerim de çevre edinebileceğin etkinliklere katılman, çevre demek fikir paylaşabileceğin, ortak çalışabileceğin kişiler demek. Unutma, insan çevresindekilerin ortalamasıdır 💪 Bu arada unutmadan staj ve stajda yaptıkların da dikkate alınabiliyor. Son iki senende part-time çalışmak da genel olarak önerilen bir kendini geliştirme yolu. Part-time iş bulamasan da dert değil, kendi projelerine zaman ayırmaya devam 😉
Topluluklar. Çevreni genişletebileceğin etkinlikler demiştim ya, topluluklar bunun için biçilmiş kaftan. Ben topluluğa katılmak yerine etkinliklerine katılmayı tercih ettim hep. Bunun kendimce sebepleri yok değil ama burada bahsetmeyeceğim 🤐 Topluluklar seninle aynı yolda olan insanlarla tanışman için güzel bir seçenek. Ayrıca toplulukların yönetiminde olmak sektör için güzel bir deneyim. Dikkat et de arada kaybolma sakın...
Kitaplar. Bölümümüzde pek de kitap kullanılmıyor, en azından dersler için. Fakat sıkça önerilen kitapları okumanı öneririm, farklı bakış açıları kazanmanda ve bu alanın büyüklerinin deneyimleri hakkında bilgi edinmende faydalı olacaklar. İşte aklıma gelenler:
- Clean Code: A Handbook of Agile Software Craftsmanship.
- The Pragmatic Programmer: From Journeyman to Master.
- Algorithms to Live By: The Computer Science of Human Decisions.
- Design Patterns: Elements of Reusable Object-Oriented Software.

Not: Burada yazanlar benim bunları yaptığımı göstermez. Bazen tavsiyeler pişmanlıklardan ders çıkararak yapılır.

Okuduğun için teşekkür ederim, bir sonraki yazıda görüşmek üzere ✌️

paylaştım bile: Yatay geçiş mi? O da ne? ↩
2026 notu: Fiyatlar artık çok daha yüksek, o yüzden öğrenci indirimlerine, yenilenmiş (refurbished) ve ikinci el seçeneklere mutlaka bak. ↩
2026 notu: yapay zekâ araçları artık günlük işin parçası. En az 16 GB RAM al; modelleri kendi bilgisayarında denemek istersen 8 GB+ VRAM’li bir ekran kartı ya da 24 GB+ birleşik belleği olan bir Mac iyi bir başlangıç. ↩
2026 notu: GitHub Student Developer Pack ile birçok araç ücretsiz, Öğrenciler için Gemini’ye de mutlaka göz at. ↩

Hasan Akalp — Writing

Ten Hours, One Click, Almost Gone: Obsidian Plugin, iCloud Recovery, and a Small Lesson

TL;DR

What I was building

Why it went wrong

The recovery moment: iCloud.com Data Recovery

The semi-technical trick: scripting a virtualized list

What I changed immediately

Conclusion

Footnotes

SlidePlay: A Local Quiz App for the Living Room

TL;DR

Why I built my own tiny quiz app

What SlidePlay is

How it works under the hood

Express + Socket.IO as the real-time backbone

Slides as data: slides.json

Scoring: correctness + speed bonus

Three browser roles: Player, Host, Admin

Player (phones and tablets)

Host (TV or projector)

Admin (laptop, tablet or phone)

Remote video control

Avatars and live reload with chokidar

The first living-room test

Closing thoughts

Footnotes

My First Oh-My-Zsh Plugin: caff

TL;DR

Why a developer needs to keep the machine awake

Amphetamine and caffeinate: the usual suspects

Amphetamine

caffeinate

The Amphetamine + clamshell problem

Why caffeinate is a better fit for my workflow

Introducing caff: a smart caffeinate wrapper

A nicer mental model

Human durations and presets

Command or no command

With a command

Without a command

Quiet mode for scripts

Why this helps my clamshell workflow

Closing thoughts

Footnotes

Yatay geçiş mi? O da ne?

Evet üniversitedesin ama o da ne...

Yatay Geçiş?

Nasıl yapılır?

Kurum içi

Kurumlar arası

Ne zaman peki?

Peki başka ne şartlar var?

Ee nasıl geçtiğimi anlayacağım?

Önceki derslerime ne olacak?

Footnotes

Bilgisayar Mühendisliği Kazandım, Ne Yapmalıyım?

Bölümü kazanmak

Kazandın, peki şimdi?

Footnotes

Slides as data: `slides.json`

Avatars and live reload with `chokidar`

Amphetamine and `caffeinate`: the usual suspects

`caffeinate`

Why `caffeinate` is a better fit for my workflow

Introducing `caff`: a smart `caffeinate` wrapper