What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

1
0
0
1
0
0
0
0
0
LiteralGrill @literalgrill@sakurajima.moe
Public
Shared by phildini

Bluesky Shits The Bed: ICE Edition

What happens when your husband gets kidnapped by ICE and you worry about it on Bluesky? Your account gets suspended, the Head of Trust and Safety trolls you on a secondary account you create to try and figure out what happened, then bans that account!

Fucking HELL what is WRONG with that site?!?

Sage Divinorum 🏳️‍⚧️ (@trans.bsky.social)

This post requires authentication to view.

bsky.app · Bluesky Social

0
0
0
0
0
0
나나나나미 @nnanananami@planet.moe
Public

SF매거진 2026년 2월호는 가공생물 특집. hayakawabooks.com/n/nb499c297c

【架空生物、全員集合！】SFマガジン2026年2月号「架空生物特集」表紙公開｜Hayakawa Books & Magazines（β）

絶賛校了中のSFマガジン2026年2月号の情報を解禁します！　年内ラストの発売となる今号は「架空生物特集」。この世には存在しない、不思議な生きものたちが主役の特集です。架空生物小説の腕に覚えあるSF作家たちが集結し、オリジナルの架空生物を考案する人もいれば、実在する可愛いアニマルや、伝説上の妖怪をもとに想像を広げる人も。特集小説計7本でお届けします、ご期待ください！ そして表紙には、特集小説に登場する架空生物たちが全員集合！　イラストはぬまがさワタリさんです。SFマガジン史上かつてなくファニーでユーモラスな表紙にもご注目ください。 ◆表紙 表紙イラスト：ぬまがさワタリ 表紙デザイン：

www.hayakawabooks.com · Hayakawa Books & Magazines（β）

0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
2
0
0
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
1
0
0
酉島伝法 @dempow@fedibird.com
Public
Shared by 나나나나미

『SFマガジン』2026年2月号は「架空生物特集」。ぬまがさワタリさんの表紙絵のインパクトあるキュートさに笑ってしまう。わたくしは「ブリーダーズ」という短編を書きました。「架空生物特集」の題字の左右でうねうねしている生き物。連載「幻視百景」にも架空生物が登場します。

hayakawabooks.com/n/nb499c297c

【架空生物、全員集合！】SFマガジン2026年2月号「架空生物特集」表紙公開｜Hayakawa Books & Magazines（β）

絶賛校了中のSFマガジン2026年2月号の情報を解禁します！　年内ラストの発売となる今号は「架空生物特集」。この世には存在しない、不思議な生きものたちが主役の特集です。架空生物小説の腕に覚えあるSF作家たちが集結し、オリジナルの架空生物を考案する人もいれば、実在する可愛いアニマルや、伝説上の妖怪をもとに想像を広げる人も。特集小説計7本でお届けします、ご期待ください！ そして表紙には、特集小説に登場する架空生物たちが全員集合！　イラストはぬまがさワタリさんです。SFマガジン史上かつてなくファニーでユーモラスな表紙にもご注目ください。 ◆表紙 表紙イラスト：ぬまがさワタリ 表紙デザイン：

www.hayakawabooks.com · Hayakawa Books & Magazines（β）

0
0
0
0
0
0
1
0
0
洪 民憙 (Hong Minhee) @hongminhee.org@bsky.brid.gy
Public

Still validating CLI option relationships with if statements? Your type system can do it for you.

Stop writing if statements for...

Stop writing if statements for your CLI flags

If you've built CLI tools, you've written code like this: if (opts.reporter === "junit" && !opts.outputFile) { throw new Error("--output-file is required for junit reporter");}if (opts.reporter === "html" && !opts.outputFile) { throw new Error("--output-file is required for html reporter");}if (opts.reporter === "console" && opts.outputFile) { console.warn("--output-file is ignored for console reporter");} A few months ago, I wrote Stop writing CLI validation. Parse it right the first time. about parsing individual option values correctly. But it didn't cover the relationships between options. In the code above, --output-file only makes sense when --reporter is junit or html. When it's console, the option shouldn't exist at all. We're using TypeScript. We have a powerful type system. And yet, here we are, writing runtime checks that the compiler can't help with. Every time we add a new reporter type, we need to remember to update these checks. Every time we refactor, we hope we didn't miss one. The state of TypeScript CLI parsers The old guard—Commander, yargs, minimist—were built before TypeScript became mainstream. They give you bags of strings and leave type safety as an exercise for the reader. But we've made progress. Modern TypeScript-first libraries like cmd-ts and Clipanion (the library powering Yarn Berry) take types seriously: // cmd-tsconst app = command({ args: { reporter: option({ type: string, long: 'reporter' }), outputFile: option({ type: string, long: 'output-file' }), }, handler: (args) => { // args.reporter: string // args.outputFile: string },});// Clipanionclass TestCommand extends Command { reporter = Option.String('--reporter'); outputFile = Option.String('--output-file');} These libraries infer types for individual options. --port is a number. --verbose is a boolean. That's real progress. But here's what they can't do: express that --output-file is required when --reporter is junit, and forbidden when --reporter is console. The relationship between options isn't captured in the type system. So you end up writing validation code anyway: handler: (args) => { // Both cmd-ts and Clipanion need this if (args.reporter === "junit" && !args.outputFile) { throw new Error("--output-file required for junit"); } // args.outputFile is still string | undefined // TypeScript doesn't know it's definitely string when reporter is "junit"} Rust's clap and Python's Click have requires and conflicts_with attributes, but those are runtime checks too. They don't change the result type. If the parser configuration knows about option relationships, why doesn't that knowledge show up in the result type? Modeling relationships with conditional() Optique treats option relationships as a first-class concept. Here's the test reporter scenario: import { conditional, object } from "@optique/core/constructs";import { option } from "@optique/core/primitives";import { choice, string } from "@optique/core/valueparser";import { run } from "@optique/run";const parser = conditional( option("--reporter", choice(["console", "junit", "html"])), { console: object({}), junit: object({ outputFile: option("--output-file", string()), }), html: object({ outputFile: option("--output-file", string()), openBrowser: option("--open-browser"), }), });const [reporter, config] = run(parser); The conditional() combinator takes a discriminator option (--reporter) and a map of branches. Each branch defines what other options are valid for that discriminator value. TypeScript infers the result type automatically: type Result = | ["console", {}] | ["junit", { outputFile: string }] | ["html", { outputFile: string; openBrowser: boolean }]; When reporter is "junit", outputFile is string—not string | undefined. The relationship is encoded in the type. Now your business logic gets real type safety: const [reporter, config] = run(parser);switch (reporter) { case "console": runWithConsoleOutput(); break; case "junit": // TypeScript knows config.outputFile is string writeJUnitReport(config.outputFile); break; case "html": // TypeScript knows config.outputFile and config.openBrowser exist writeHtmlReport(config.outputFile); if (config.openBrowser) openInBrowser(config.outputFile); break;} No validation code. No runtime checks. If you add a new reporter type and forget to handle it in the switch, the compiler tells you. A more complex example: database connections Test reporters are a nice example, but let's try something with more variation. Database connection strings: myapp --db=sqlite --file=./data.dbmyapp --db=postgres --host=localhost --port=5432 --user=adminmyapp --db=mysql --host=localhost --port=3306 --user=root --ssl Each database type needs completely different options: SQLite just needs a file path PostgreSQL needs host, port, user, and optionally password MySQL needs host, port, user, and has an SSL flag Here's how you model this: import { conditional, object } from "@optique/core/constructs";import { withDefault, optional } from "@optique/core/modifiers";import { option } from "@optique/core/primitives";import { choice, string, integer } from "@optique/core/valueparser";const dbParser = conditional( option("--db", choice(["sqlite", "postgres", "mysql"])), { sqlite: object({ file: option("--file", string()), }), postgres: object({ host: option("--host", string()), port: withDefault(option("--port", integer()), 5432), user: option("--user", string()), password: optional(option("--password", string())), }), mysql: object({ host: option("--host", string()), port: withDefault(option("--port", integer()), 3306), user: option("--user", string()), ssl: option("--ssl"), }), }); The inferred type: type DbConfig = | ["sqlite", { file: string }] | ["postgres", { host: string; port: number; user: string; password?: string }] | ["mysql", { host: string; port: number; user: string; ssl: boolean }]; Notice the details: PostgreSQL defaults to port 5432, MySQL to 3306. PostgreSQL has an optional password, MySQL has an SSL flag. Each database type has exactly the options it needs—no more, no less. With this structure, writing dbConfig.ssl when the mode is sqlite isn't a runtime error—it's a compile-time impossibility. Try expressing this with requires_if attributes. You can't. The relationships are too rich. The pattern is everywhere Once you see it, you find this pattern in many CLI tools: Authentication modes: const authParser = conditional( option("--auth", choice(["none", "basic", "token", "oauth"])), { none: object({}), basic: object({ username: option("--username", string()), password: option("--password", string()), }), token: object({ token: option("--token", string()), }), oauth: object({ clientId: option("--client-id", string()), clientSecret: option("--client-secret", string()), tokenUrl: option("--token-url", url()), }), }); Deployment targets, output formats, connection protocols—anywhere you have a mode selector that determines what other options are valid. Why conditional() exists Optique already has an or() combinator for mutually exclusive alternatives. Why do we need conditional()? The or() combinator distinguishes branches based on structure—which options are present. It works well for subcommands like git commit vs git push, where the arguments differ completely. But in the reporter example, the structure is identical: every branch has a --reporter flag. The difference lies in the flag's value, not its presence. // This won't work as intendedconst parser = or( object({ reporter: option("--reporter", choice(["console"])) }), object({ reporter: option("--reporter", choice(["junit", "html"])), outputFile: option("--output-file", string()) }),); When you pass --reporter junit, or() tries to pick a branch based on what options are present. Both branches have --reporter, so it can't distinguish them structurally. conditional() solves this by reading the discriminator's value first, then selecting the appropriate branch. It bridges the gap between structural parsing and value-based decisions. The structure is the constraint Instead of parsing options into a loose type and then validating relationships, define a parser whose structure is the constraint. Traditional approachOptique approachParse → Validate → UseParse (with constraints) → UseTypes and validation logic maintained separatelyTypes reflect the constraintsMismatches found at runtimeMismatches found at compile time The parser definition becomes the single source of truth. Add a new reporter type? The parser definition changes, the inferred type changes, and the compiler shows you everywhere that needs updating. Try it If this resonates with a CLI you're building: Documentation Tutorial conditional() reference GitHub Next time you're about to write an if statement checking option relationships, ask: could the parser express this constraint instead? The structure of your parser is the constraint. You might not need that validation code at all.

hackers.pub · Hackers' Pub

Link author: 洪 民憙 (Hong Minhee)@hongminhee@hackers.pub

0
0
0
0
0
1
0
0
0
0
0
0
sublimer@あすてろいどん鯖管 @sublimer@mstdn.sublimer.me
Public

> maintain-framerate-and-resolution は、WebRTC の内部動画適応を無効にします。これにより、アプリケーションは独自の適応ロジックを実装し、内部適応による干渉を防ぐことができます。

Chrome 144 ベータ版 | Blog | Chrome for Developers : 👀
---
developer.chrome.com/blog/chro

Chrome 144 ベータ版  |  Blog  |  Chrome for Developers

Chrome に搭載される最新機能について学びます。

developer.chrome.com · Chrome for Developers

0
0
0
0
0
0
1
0
0
0
0
0
1
0
0
酉島伝法 @dempow@fedibird.com
Public

『SFマガジン』2026年2月号は「架空生物特集」。ぬまがさワタリさんの表紙絵のインパクトあるキュートさに笑ってしまう。わたくしは「ブリーダーズ」という短編を書きました。「架空生物特集」の題字の左右でうねうねしている生き物。連載「幻視百景」にも架空生物が登場します。

hayakawabooks.com/n/nb499c297c

【架空生物、全員集合！】SFマガジン2026年2月号「架空生物特集」表紙公開｜Hayakawa Books & Magazines（β）

絶賛校了中のSFマガジン2026年2月号の情報を解禁します！　年内ラストの発売となる今号は「架空生物特集」。この世には存在しない、不思議な生きものたちが主役の特集です。架空生物小説の腕に覚えあるSF作家たちが集結し、オリジナルの架空生物を考案する人もいれば、実在する可愛いアニマルや、伝説上の妖怪をもとに想像を広げる人も。特集小説計7本でお届けします、ご期待ください！ そして表紙には、特集小説に登場する架空生物たちが全員集合！　イラストはぬまがさワタリさんです。SFマガジン史上かつてなくファニーでユーモラスな表紙にもご注目ください。 ◆表紙 表紙イラスト：ぬまがさワタリ 表紙デザイン：

www.hayakawabooks.com · Hayakawa Books & Magazines（β）

0
0
0
0
0
0
0
0
0
0
0
0

Stop writing if statements for your CLI flags

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

If you've built CLI tools, you've written code like this:

if (opts.reporter === "junit" && !opts.outputFile) {
  throw new Error("--output-file is required for junit reporter");
}
if (opts.reporter === "html" && !opts.outputFile) {
  throw new Error("--output-file is required for html reporter");
}
if (opts.reporter === "console" && opts.outputFile) {
  console.warn("--output-file is ignored for console reporter");
}

A few months ago, I wrote Stop writing CLI validation. Parse it right the first time. about parsing individual option values correctly. But it didn't cover the relationships between options.

In the code above, --output-file only makes sense when --reporter is junit or html. When it's console, the option shouldn't exist at all.

We're using TypeScript. We have a powerful type system. And yet, here we are, writing runtime checks that the compiler can't help with. Every time we add a new reporter type, we need to remember to update these checks. Every time we refactor, we hope we didn't miss one.

The state of TypeScript CLI parsers

The old guard—Commander, yargs, minimist—were built before TypeScript became mainstream. They give you bags of strings and leave type safety as an exercise for the reader.

But we've made progress. Modern TypeScript-first libraries like cmd-ts and Clipanion (the library powering Yarn Berry) take types seriously:

// cmd-ts
const app = command({
  args: {
    reporter: option({ type: string, long: 'reporter' }),
    outputFile: option({ type: string, long: 'output-file' }),
  },
  handler: (args) => {
    // args.reporter: string
    // args.outputFile: string
  },
});
// Clipanion
class TestCommand extends Command {
  reporter = Option.String('--reporter');
  outputFile = Option.String('--output-file');
}

These libraries infer types for individual options. --port is a number. --verbose is a boolean. That's real progress.

But here's what they can't do: express that --output-file is required when --reporter is junit, and forbidden when --reporter is console. The relationship between options isn't captured in the type system.

So you end up writing validation code anyway:

handler: (args) => {
  // Both cmd-ts and Clipanion need this
  if (args.reporter === "junit" && !args.outputFile) {
    throw new Error("--output-file required for junit");
  }
  // args.outputFile is still string | undefined
  // TypeScript doesn't know it's definitely string when reporter is "junit"
}

Rust's clap and Python's Click have requires and conflicts_with attributes, but those are runtime checks too. They don't change the result type.

If the parser configuration knows about option relationships, why doesn't that knowledge show up in the result type?

Modeling relationships with conditional()

Optique treats option relationships as a first-class concept. Here's the test reporter scenario:

import { conditional, object } from "@optique/core/constructs";
import { option } from "@optique/core/primitives";
import { choice, string } from "@optique/core/valueparser";
import { run } from "@optique/run";

const parser = conditional(
  option("--reporter", choice(["console", "junit", "html"])),
  {
    console: object({}),
    junit: object({
      outputFile: option("--output-file", string()),
    }),
    html: object({
      outputFile: option("--output-file", string()),
      openBrowser: option("--open-browser"),
    }),
  }
);

const [reporter, config] = run(parser);

The conditional() combinator takes a discriminator option (--reporter) and a map of branches. Each branch defines what other options are valid for that discriminator value.

TypeScript infers the result type automatically:

type Result =
  | ["console", {}]
  | ["junit", { outputFile: string }]
  | ["html", { outputFile: string; openBrowser: boolean }];

When reporter is "junit", outputFile is string—not string | undefined. The relationship is encoded in the type.

Now your business logic gets real type safety:

const [reporter, config] = run(parser);

switch (reporter) {
  case "console":
    runWithConsoleOutput();
    break;
  case "junit":
    // TypeScript knows config.outputFile is string
    writeJUnitReport(config.outputFile);
    break;
  case "html":
    // TypeScript knows config.outputFile and config.openBrowser exist
    writeHtmlReport(config.outputFile);
    if (config.openBrowser) openInBrowser(config.outputFile);
    break;
}

No validation code. No runtime checks. If you add a new reporter type and forget to handle it in the switch, the compiler tells you.

A more complex example: database connections

Test reporters are a nice example, but let's try something with more variation. Database connection strings:

myapp --db=sqlite --file=./data.db
myapp --db=postgres --host=localhost --port=5432 --user=admin
myapp --db=mysql --host=localhost --port=3306 --user=root --ssl

Each database type needs completely different options:

  • SQLite just needs a file path
  • PostgreSQL needs host, port, user, and optionally password
  • MySQL needs host, port, user, and has an SSL flag

Here's how you model this:

import { conditional, object } from "@optique/core/constructs";
import { withDefault, optional } from "@optique/core/modifiers";
import { option } from "@optique/core/primitives";
import { choice, string, integer } from "@optique/core/valueparser";

const dbParser = conditional(
  option("--db", choice(["sqlite", "postgres", "mysql"])),
  {
    sqlite: object({
      file: option("--file", string()),
    }),
    postgres: object({
      host: option("--host", string()),
      port: withDefault(option("--port", integer()), 5432),
      user: option("--user", string()),
      password: optional(option("--password", string())),
    }),
    mysql: object({
      host: option("--host", string()),
      port: withDefault(option("--port", integer()), 3306),
      user: option("--user", string()),
      ssl: option("--ssl"),
    }),
  }
);

The inferred type:

type DbConfig =
  | ["sqlite", { file: string }]
  | ["postgres", { host: string; port: number; user: string; password?: string }]
  | ["mysql", { host: string; port: number; user: string; ssl: boolean }];

Notice the details: PostgreSQL defaults to port 5432, MySQL to 3306. PostgreSQL has an optional password, MySQL has an SSL flag. Each database type has exactly the options it needs—no more, no less.

With this structure, writing dbConfig.ssl when the mode is sqlite isn't a runtime error—it's a compile-time impossibility.

Try expressing this with requires_if attributes. You can't. The relationships are too rich.

The pattern is everywhere

Once you see it, you find this pattern in many CLI tools:

Authentication modes:

const authParser = conditional(
  option("--auth", choice(["none", "basic", "token", "oauth"])),
  {
    none: object({}),
    basic: object({
      username: option("--username", string()),
      password: option("--password", string()),
    }),
    token: object({
      token: option("--token", string()),
    }),
    oauth: object({
      clientId: option("--client-id", string()),
      clientSecret: option("--client-secret", string()),
      tokenUrl: option("--token-url", url()),
    }),
  }
);

Deployment targets, output formats, connection protocols—anywhere you have a mode selector that determines what other options are valid.

Why conditional() exists

Optique already has an or() combinator for mutually exclusive alternatives. Why do we need conditional()?

The or() combinator distinguishes branches based on structure—which options are present. It works well for subcommands like git commit vs git push, where the arguments differ completely.

But in the reporter example, the structure is identical: every branch has a --reporter flag. The difference lies in the flag's value, not its presence.

// This won't work as intended
const parser = or(
  object({ reporter: option("--reporter", choice(["console"])) }),
  object({ 
    reporter: option("--reporter", choice(["junit", "html"])),
    outputFile: option("--output-file", string())
  }),
);

When you pass --reporter junit, or() tries to pick a branch based on what options are present. Both branches have --reporter, so it can't distinguish them structurally.

conditional() solves this by reading the discriminator's value first, then selecting the appropriate branch. It bridges the gap between structural parsing and value-based decisions.

The structure is the constraint

Instead of parsing options into a loose type and then validating relationships, define a parser whose structure is the constraint.

Traditional approach Optique approach
Parse → Validate → Use Parse (with constraints) → Use
Types and validation logic maintained separately Types reflect the constraints
Mismatches found at runtime Mismatches found at compile time

The parser definition becomes the single source of truth. Add a new reporter type? The parser definition changes, the inferred type changes, and the compiler shows you everywhere that needs updating.

Try it

If this resonates with a CLI you're building:

  • Documentation
  • Tutorial
  • conditional() reference
  • GitHub

Next time you're about to write an if statement checking option relationships, ask: could the parser express this constraint instead?

The structure of your parser is the constraint. You might not need that validation code at all.

Read more →
4
0
1
0
0
1
0
0
0
하와와못하는딜🕯️ @gwang0dilo@planet.moe
Public
Shared by 힐씨

예전엔 인터넷상의 정보가 불확실하다면 잘 정리된 책을 참고하라고 할 수라도 있었는데 이젠 ai로 생성한 신뢰 불가능한 책을 잔뜩 찍어내기까지 하고 있으니…. 종이값도 비싼데 저런 놈들 때문에 펄프 가격만 더 올라가잖아! 동인지 가격 비싸진다고! 안 그래도 소량이라 출력도 비싼데 가격 더 올라간다고!

0
0
1
하와와못하는딜🕯️ @gwang0dilo@planet.moe
Public
Shared by 시오

예전엔 인터넷상의 정보가 불확실하다면 잘 정리된 책을 참고하라고 할 수라도 있었는데 이젠 ai로 생성한 신뢰 불가능한 책을 잔뜩 찍어내기까지 하고 있으니…. 종이값도 비싼데 저런 놈들 때문에 펄프 가격만 더 올라가잖아! 동인지 가격 비싸진다고! 안 그래도 소량이라 출력도 비싼데 가격 더 올라간다고!

0
0
1
1
0
0
1
0
0
0
0
0
0
0
0
하와와못하는딜🕯️ @gwang0dilo@planet.moe
Public

예전엔 인터넷상의 정보가 불확실하다면 잘 정리된 책을 참고하라고 할 수라도 있었는데 이젠 ai로 생성한 신뢰 불가능한 책을 잔뜩 찍어내기까지 하고 있으니…. 종이값도 비싼데 저런 놈들 때문에 펄프 가격만 더 올라가잖아! 동인지 가격 비싸진다고! 안 그래도 소량이라 출력도 비싼데 가격 더 올라간다고!

0
0
1
1
0
0
1
0
0
1
0
0
0
0
0
1
0
0
0
0
0
0
1
0