
『[Software Engineering at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』の第一章「What Is Software Engineering」を読んだ感想をメモしていく。

## Hyrum's Law (ハイラムの法則)

この章では「[Hyrum's Law](https://www.hyrumslaw.com/)」という言葉が導入される。本書の後の方でも何度か言及されるキーワードである。「Hyrum...誰...??」と思ったけど、これは著者の Hyrum Wright さんのことのようだ。

本には次のように書かれている。

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
> 
> (抄訳) 十分な数の API 利用者がいれば、契約で約束した内容は重要ではありません。あなたのシステムで観測できる挙動はすべて、誰かに依存されることになります。

これはどういうことを言っているのだろうか。書籍ではハッシュコンテナを例に説明しているけど、もう少し具体的に Python で Hyrum's Law に該当する例を示してみよう。

かつて Python では dict オブジェクトのデータ挿入順は保持されなかった。しかし [バージョン 3.7 からは dict オブジェクトの挿入順序が保存される](https://docs.python.org/ja/3/whatsnew/3.7.html)。それでは、`dict` がデータの挿入順を保持することに依存するコードを書いて良いのかというと、そうとは言い切れない。未来のバージョンでは、この振る舞いが変わる可能性もある。

そして「**システムで観測できる挙動はすべて、誰かに依存される**」というのは、過去の Python では dict を疑似ランダマイザーとして使うプログラマーがいた、という意味だ。**たまたま** 未定義の振る舞いを観測したプログラマーが、それに依存したコードを書いてしまうのである。

プログラミング言語の未定義な振る舞いを活用したプログラムは「賢い」プログラムである。しかし、このような「賢さ」はソフトウェアエンジニアリングの文脈では褒められるものではない、とある。

## Trade-offs and Costs (トレードオフとコスト)

組織の健全性はキャッシュフローだけの問題ではない。次の一節は素晴らしい話だと思った。

> Efficiency gains from keeping engineers happy, focused, and engaged can easily dominate other factors, simply because focus and productivity are so variable, and a 10-to-20% difference is easy to imagine.
> 
> (抄訳) エンジニアが幸せで、集中し、仕事に打ち込むことで得られる効率性は、他の要因を圧倒します。なぜなら、集中力と生産性は非常に変わりやすく、10～20%の差は簡単に想像できるからです。

組織がエンジニアの幸福に投資することは、福利厚生ではない。組織の成長のための戦略である。

「10~20% の差」という数字の根拠は特に書かれていなかったけど、少なく見積もってもその程度の差はあるだろう。



Software Engineering at Google: Chapter 1 - What Is Software Engineering


[IIJ Engineering Blog の「その証明書、安全ですか？」という記事](https://eng-blog.iij.ad.jp/archives/17668)を読んだ。小難しい話をユーモアをまじえて解説する、良い記事だと思った。

この記事の「事例3: KLAYswap」のところに次のように書かれている。

> この事例でハイジャックされたのはKLAYswap自体ではなく、KLAYswapが利用するJavaScriptのライブラリが置かれていた外部のサイトでした。KLAYswapにアクセスしたユーザは、偽の外部サイトから改竄されたJavaScriptファイルをダウンロードし、それを実行して仮想通貨を奪われました。
 
これは個人的には古傷をえぐられる事例で、過去にコードレビューで「みだりに外部ドメインのリソースを読むべきではなく、可能な限り自分たちで管理できるドメインにリソースを移動して使うべきである」と主張したものの「考えすぎだ」と却下されたことがある。僕の言葉遣いがいたらなかったのかもしれないし、いわゆる信頼残高が足りなかったのかもしれない。しかし、具体的にそういう事例を例示できれば説得力も増すものだし、記憶に留めておこうと思った。


外部ドメインでホストされているリソースをみだりに読み込むべきではないという話


この記事は Dropbox で Principal Engineer をされていた James Cowling さんによる [Don’t lead by example](https://blogs.dropbox.com/tech/2019/02/dont-lead-by-example/) というページの翻訳です。この記事が最初にリリースされたとき、強く感銘を受けたことを覚えています。ふと個人的なメモを漁っていたところ、この記事を過去に翻訳したことを思い出し、ここで公開しようと思いました。

## "お手本になる" ことでリードしてはならない

はじめて Dropbox でテックリードの役職についたとき、ふたつの手強い仕事を請け負うことになりました。

1. 数エクサバイトの分散ストレージシステムを作り、S3 にあるデータを置き換えること。しかも、厳しいリソースとタイトなスケジュールの中で。
2. テックリードというよくわからない仕事を理解すること。

後者の方は想像よりもずっと難しいことでした。

チームが少ない内はなんでもうまくいきますが、成長とともに痛みがはじまります。チームメンバーが、するべき汚れ仕事をきちんとしているように思えませんでした。いつも少数の決まったメンバーが緊急事態に対応し、アラートを受け取り、ダッシュボードを修正し、サービスを継続させているように思えたのです。わたし自身もその「少数のメンバー」のひとりであり、イラつきはじめていました。この事態に対して "どう対処すべきか模範となって示そう" と考えました。

わたしは一層がんばって、チームのお手本になろうとしました。どのアラートにも即座に対応し、メールに誰よりも速く返信し、チャットで流れてくる質問にも頻繁に答えました。一日に16時間も働き、チームのオンボーディングに四苦八苦しましたが、いささか度を越していました。この後に何が起こったか、ご想像がつくでしょう。

わたしが首を突っ込むほど他のメンバーは萎縮し、わたしの方が問題を簡単に解決できるのではないかと思うようになりました。メンバーはマイクロマネージされていると感じ、自信をなくしました。メンバーが「彼は一日中働くのが好きなのかも」と思うほど、わたしは「みんながついてきてくれない」と悩むようになりました。わたしが努力するほどにチームメンバーは不幸せになり、わたしは燃え尽き、仕事の進捗も悪くなりました。より経験のあるテックリードに **「お手本になることでリードするのは止めよう」** と言われるまで、これは続きました。

この言葉の意味を理解するには、しばらくの時間が必要でした。

### リーダーシップには適切な期待値の設定が必要である

「何がよい振る舞いなのか」を規定することは必要だけど、お手本になることでリードをするのはうまいやり方ではないし、受動的攻撃行動 *(passive-aggressive)* だとも言えます。よいリーダーは分かりやすくコミュニケーションし、適切な期待値を設定し、チームメンバーが能動的に動けるように指導します。ぐっとこらえて、ロールにしたがいましょう。

とりわけ重要なのは、チーム内でオンコールのメンバーに対する期待値と責任範囲を明確に話しておくことです。最初は億劫に思えましたが、チームメンバーは期待値設定を明確にすることに好感を持ちました。わたしは少し冷静になることを求められました。メールに即座に反応する必要はないし、いつも大問題が起こっているわけではないのです。期待値を明文化することで、何が価値のある仕事で、何がマイクロマネジメントなのかを考えさせられるようになりました。

期待値設定はアカウンタビリティの概念とよく合います。つまり、人々を期待に応えるように導けるのです。これは大きなトピックで、これだけでブログ記事をひとつ書けるほどです。重要なことは、優秀なエンジニアは監視ではなくアカウンタビリティのある場所でもっとも能力を発揮するということです。人々が期待に応えたくなるよう仕向けるために必要なものは何でしょうか?

ずばり、期待値を設定することです。

### 誰もが等しく汚れ仕事をする

素晴らしい。期待値を設定することで、全員の気持ちが "引き上げられ" ましたね。それではふかふかの椅子にゆったりと座って、チームが機能するところをじっくり眺めましょうか。...おっと、それはよくない。さあ、よそ行きの服を脱ぎ捨てて現場に戻りましょう。

モダンな技術者は控えめに言っても反権威主義です。あなたがテックリードというロールを「ボスとして振る舞うこと」だと考えているのであれば、チームからの信用を即座に失うことでしょう。

期待値設定はテックリードの仕事のひとつですが、あなた自身もチームメンバーのひとりであることを忘れてはいけません。あなたも現場で実際の仕事をする必要があるのです。現場でチームメンバーと仕事をすることが品質を高めることにつながり、システムを理解し、チームメンバーの気持ちを理解し、チームが目的を達成するための助けになります。あなたはチームでもっともハードワーキングなメンバーとなるでしょう。おめでとう。テックリードの世界へようこそ。

### まとめ

"お手本になる" ことでリードしてもうまくいきません。「何がよい振る舞いなのか」を規定することは重要ですが、強いリーダーシップには不十分です。テックリードとして振る舞うというのは、明確な期待値の設定をし、忌憚ないコミュニケーションを重視することです。ただし、思い上がってはいけません。あなたはチームメンバーであって、ボスではないのです。


Don't Lead by example の日本語訳


『[プログラミングTypeScript](https://www.oreilly.co.jp/books/9784873119045/)』の第五章では、Java などのプログラミング言語における `final` キーワードを TypeScript で実現するアイディアについて紹介されている。面白いと思った。

Java の `final` は色々なところに書けるが、ここではクラスに対する `final` について考える。クラスに対して `final` をつけると、そのクラスは継承できなくなる。

TypeScript で継承不可能なクラスを定義するにはどうすれば良いだろう? [コンストラクタを `private` にすれば継承は不可能になる](https://www.typescriptlang.org/play?#code/MYGwhgzhAECyYFsFhNA3gKGtADgJwEsA3MAFwFNpgB7AOwlLwFdhTq8AKASnQF8N+GUJBgARagHNo5AB4VaAExjwkKPhiF0G0BZOgBeaLXIB3aOIncMQA)。

```typescript
class Mammal {
  private constructor() {}
}

class Dog extends Mammal {}

const dog = new Dog()
```

このとき `class Dog extends Mammal {}` に対するエラーメッセージは `Cannot extend a class 'Mammal'. Class constructor is marked as private.(2675)` である。また `const dog = new Dog()` については `Constructor of class 'Mammal' is private and only accessible within the class declaration.(2673)` と言われる。エラーメッセージがすべてを言い表している。

ところで Java の `final` は継承を禁止するだけで `final` のついたクラスのインスタンス化を禁止するものではない。この修飾子をエミュレートするのであれば `const dog = new Dog()` 相当のものは許したい。`private` なコンストラクタを外から呼べない、という制約があるので `Mammal` クラスの中でインスタンスを作れば良いだろう。[具体的には次のようにする](https://www.typescriptlang.org/ja/play?#code/MYGwhgzhAECyYFsFhNA3gKGtADgJwEsA3MAFwFNpgB7AOwlLwFdhTq8AKASnQF8toDMgWBU85MuW7oB2caSZ5a0WuQDucRMhDcB-fhhr1S0ZEhTQAvJvMgAdMHGTdQA)。

```typescript
class Mammal {
  private constructor() {}
  static create() {
    return new Mammal()
  }
}

const mammal = Mammal.create()
```

これで Mammal は継承不可であり、そのインスタンスは `Mammal.create()` によって得られるようになった。





『プログラミングTypeScript』 第四章 - final 修飾子のエミュレート


[2022 年の振り返り記事](/posts/2022-12-23-retrospective)で Twitter 離れしたことを書いた。

> ソーシャルメディアに対する熱はだいぶ冷めてしまっており、Twitter にもぽつぽつとしか投稿していなかったところ、イーロン・マスクにより Twitter が買収された。買収に関する見方は様々あると思うけど、ニュースや (元) 社員 のツイートを読む限り、僕はネガティブなイベントだと捉えており、Twitter からは距離を置きたいと思うようになった。

今なお Twitter に対する不信感は募る一方だけど、Twitter から離れたことによる弊害も感じるようになった。何かというと、技術的なトレンドを把握する方法を失った、ということである。Twitter で僕がフォローしていた人たちの多くはギークであり、彼らが発信するものを追うだけでトレンドがわかった。

Twitter を使わずに同じ体験をするために RSS リーダーを使うことにした。**2023 年に、RSS リーダー、だ**。僕と同世代の人であれば、Livedoor Reader や Google Reader などの優れた RSS リーダーが 2010 年代にサービス終了したことを覚えているだろう。外野からは想像しかできないけど、それらの RSS リーダーを追いやったものこそが Twitter などのソーシャルメディアだと思う。

この仮定が正しければ、Twitter から離れた今こそ RSS リーダーで情報収集をするべきではないか。そう思い、今は [Feedly](https://feedly.com/) を試している。Feedly を一日に数回開くことで、技術トレンドはそれなりに追えている。Twitter がフォローする人次第で体験が変わるように、Feedly も登録する RSS フィードでだいぶ体験が変わる。Feedly に好きなブロガーやニュースサイトの RSS フィードを登録すると、似たフィードをレコメンドしてくれるので、満足できる記事が出ている。

ところで、小ネタとして [Feedly Background Tab](https://chrome.google.com/webstore/detail/feedly-background-tab/gjlijkhcebalcchkhgaiflaooghmoegk) という Chrome Extension を推したい。これをインストールすると `;` で Feedly を離れずに URL を新規タブで開ける。`j` と `k` でフィードをスクロールしながら `;` でタブをどんどん開き、最後にタブをまとめて消化する、というスタイルで記事を読める。

もし願いが叶うのであれば、僕の友人にはブログ記事 **も** 書いてほしい。Twitter 上で仲良くさせてもらっていた方々のブログは Feedly に登録しているので、彼らのテキストが Feedly から流れてくれば、とても嬉しい 🤗


RSS リーダーへの回帰


[2022 年の振り返り記事](/posts/2022-12-23-retrospective)でマークダウンエディタとして [MarkText](https://marktext.app/) を使っていると書いた。

> MarkText は手元で (ほぼ) 処理が完結するので、さくさく動いて今のところ重宝している。実は細かな挙動で不満があるにはあるけど、我慢できる範囲である。

ところが、ここに来て「細かな挙動による不満」が溜まってしまい、MarkText を使うのをやめた。具体的にはリストを書いているときに Emacs キーバインドが効かなかったり、URL をコピペしたときにタイトルを展開する挙動が一貫していない (...ように見える) ことである。ひどいときには undo と redo の挙動が変 (...に見える) ときもあった。たとえば undo を数回くりかえした後で redo してもテキストを元の状態に戻せない、など。

自分で問題解決を試みようかとも思ったけど、そもそもビルドが手元の環境ですんなりできず、ここで頑張るくらいなら何かに乗り換えようという気持ちになってしまった。

乗り換え先だけど、単に IntelliJ でマークダウンファイルを編集するので十分だと気づいてしまった。きれいな WYSIWYG 機能はないけど、リアルタイムプレビューは可能だし、IntelliJ のファイル編集機能は手に馴染んだものである。

![IntelliJ での初稿のプレビュー](/images/20230119-markdown-to-intellij.png)

テキストファイルをいじるのに専用のソフトウェアは不要である。オーバーエンジニアリングしない。そういう気持ちをあらたにした。


MarkText から IntelliJ への移行


GitHub プロジェクトにスターをつけるとき、だいたいはブックマーク目的である。しかし、この運用には根本的な問題がある。スターをつけたプロジェクトを忘れてしまうのだ。

そこで、[スターをつけたプロジェクトを取得してきてランダムに Slack に通知するプログラムを書いた](https://gist.github.com/mahata/88ec9f7d4ca7eed9f9c6aa9e2147ee1c)。これを動かすと、次のようなメッセージが Slack に投稿される。

![GitHub にスターをつけたリポジトリ](/images/20230118-github-stars.png)

先日、[GitHub Actions を cron サーバーとして運用する話](/posts/2023-01-17-github-actions-as-a-cron-server)を書いた。これと同じように、GitHub Actions にスターをつけたプロジェクトを定期的に Slack に投稿してもらい、記憶を掘り起こしてもらうようにした。


GitHub でスターをつけたプロジェクトを定期的にリマインドする話


何かの処理を定期的に実行したい、そんなこともあるでしょう。プログラマであれば。

[過去には `Launchd` で MacBook から定期的に Slack メッセージをポストしたりしていた](https://mahata.gitlab.io/post/2021-04-01-read-your-own-blog/)。これには概ね満足していたけど、いくつか気になる点もあった。

1. 手元の MacBook で `Launchd` が動いているため、マシンを落としていると処理を実行できない
2. 複数の MacBook があると、どこの `Launchd` に何を設定したか管理しづらい

これを克服するため GitHub Actions を cron サーバーのように運用することにした。

[GitHub Actions は `on.schedule.cron` で起動タイミングを設定できる](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)。この機能を使い、任意のタイミングで任意のコマンドを実行できる。GitHub Actions は (障害が起きていない限り) 常に利用可能なので、MacBook の `Launchd` より高い可用性を期待できる。

ひとつ設定時にはまったのは、GitHub Actions の最短の実行間隔が 5 分だということだ。ドキュメントにはこう書かれている。

> The shortest interval you can run scheduled workflows is once every 5 minutes.

つまり `cron: '*/2 * * * *'` のようには書けない。僕は試行錯誤のために毎分 GitHub Actions をトリガーしようと思ったが、うまくアクションが動かずに「あれーなんでだろう...」となってしまった。


定期的な処理を GitHub Actions で行う話


『[プログラミングTypeScript](https://www.oreilly.co.jp/books/9784873119045/)』の第四章の練習問題に次のようなものがある。

> 5. 型安全なアサーション関数、isを実装してください。型で概略を記述することから始めます。これは、完成したら、次のように使えるものです。
>
>   ```typescript
>   // stringとstringを比較します
>   is('string', 'otherstring') // false
>   
>   // booleanとbooleanを比較します
>   is(true, false) // false
>   
>   // numberとnumberを比較します
>   is(42, 42) // true
>   
>   // 異なる型同士を比較すると、コンパイル時エラーになります
>   is(10, 'foo') // エラー TS2345: 型 '"foo"' の引数を型 'number' の
>                 // パラメーターに割り当てることはできません。
>   ```

よしよし、そんなに難しくはなさそうだ。この章の後半で出てきたジェネリック型を使えばできるのだろう。こうかな?

```typescript
function is<T>(first: T, second: T) {
  return first === second;
}
```

[動いているようだな](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABDAzgHgCoD4AUwYBOKUAXIhgDSIoCmECAJmRgJSIDeAUIogTVCAJJ8RKIgC8k6nUYBuTgF9OnemBRwANjQB0GuAHMcqHAHJiBGGH0mqJuFAAWNURasmWLWYgD03xMABDDVoVBHUtXQMjFBwoAhAaKkDgmg8vX38gkNVwnT1DYwAWACYqErSfPziEzgzjAEYABltgODh3SsRACoZAS4ZAH4ZyAGVigGZCgFYyQGj1RBMAIla4OZNEQDsGQFR9QAdTQCSGGZMwEABbACNnFdXARYYewEOGPsB+hj7AawZAJyVAKIZAZX1AMwZAaIZAZQZACwZAPYMgHMGQCyDIA-BkA2gyAZIZAEAMnCAA)。おっ、この問題には続きがあるようだ...

```typescript
// ［難問］任意の数の引数を渡せるようにします
is([1], [1, 2], [1, 2, 3]); // false
```

ふむふむ、何個の引数が渡されるかわからないのであれば、レストパラメーターを使えばいけるだろう。俺は詳しいんだ。

```typescript
function is<T>(first: T, ...rest: T[]) {
  return rest.every(_ => _ === first);
}
```

うんうん、[これも期待通りに動くな](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABDAzgHgCoD4AUwYBOKUAXIhgDSIB0tBApsWRgNoC6AlIgN4BQiiBlBAEkDYtXoA3egQCeOAPqIAvFkTKVWxPiJQOAbl4BfXrwgIUcADb1q1uAHMcqHAHJiBGGEduqbuCgAC1lPb18OQ0QAemidAENrFHpzSxs7B2dXKAIQeipgROTIgxi4wqSUizArW3snFxQcABYAJio2krLEHLzeWOQmgEYABn9gODg3LgHACoZAS4ZAH4ZyAGVWgGZmgFYyQGj1RDcAIgm4Q7dEQDsGQFR9QAdTQCSGfbcwEABbACNZc4vARYZ5wEOGRaAfoZFoBrBkATkqAKIZAMr6gDMGQDRDIBlBkAFgyAewZAOYMgFkGQB+DIBtBkAyQyAIAZUjV0vUsk0WEM2FRKVRWtTELTEO1EOtOFEBhVkkA)。ここで本の解答を眺めると...あれ、ちょっと僕の書いたものとは違う。

```typescript
function is<T>(first: T, ...rest: [T, ...T[]]): boolean {
  return rest.every(_ => _ === first)
}
```

...あっ、なるほど。もとの `...rest: T[]` だと `is('foo')` のような入力も許されてしまうのか...これは失態だ。`rest` が少なくともひとつの要素をもつことを保証するためには `...rest: [T, ...T[]]` [のように書く必要がある](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABDAzgHgCoD4AUwYBOKUAXIhgDSIB0tBApsWQNqU20bMC6XAlGQCM4cADb0AhkgDeAKESIGUEASQNi1egDd6BAJ44A+ogC8WREeOXE+IlF4yAvjJkQEKUfWoi4AcxyocAHJiAhgwH0CqQLgoAAsdELCI3l4AbkQAegzrcREUehc3Dy9ffxQcKAIQeipgXPyU9KycvILXMHcxEr8AgBYAJioBxszsyuqZZoCARgAGKOBhQN5RxEAKhkBLhkAfhnIAZX6AZl6AVjJAaPVEQIAiRbgrwMRAOwZAVH1AB1NAJIYLwLAQAFsBHQPR6ARYYNoBDhi2gH6GLaAawZAE5KgCiGQDK+oAzBkA0QyAZQZABYMgHsGQDmDIBZBkAfgyAbQZAMkMgCAGQodYreHrlZjTLhURlUfrMxCsxCDRAHPhpVZ1VqTbIBQK3ZarACiAA8AA70aD0AAmiHEUEQYnExG5aoIPj+9DAUBQVAEIA1PhiiGm1BkQA)。

こういうケースには自分で気づけないといけないな。


『プログラミングTypeScript』 第四章 - is メソッドの実装


『[プログラミングTypeScript](https://www.oreilly.co.jp/books/9784873119045/)』の第四章ではジェネレーターおよびイテレーターに関するセクションがある。そこではフィボナッチ数を生成するジェネレーターを返す関数 (ジェネレーター関数) が例示されている。

本記事では「素数を生成するジェネレーター」を返す関数を書いてみよう。素数は無限に存在するので、**次の**素数を返せるというのはジェネレーターの用途として適切だろう。

[全体のコードは次の通り](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABAKggJwKYEMoYApowC2GA4hmBmjnGgBQCUiA3gFCKIQIDOUiADoRLdEAXkSUA7ogDKGKAB4wIIgCMqAPkat2iADbzOINJjB9xAJl2SAFjAOI6UNCAxM2HDrfsZHz1+66nvqGMNwExL7i-hhBnsC0jlxgvAJCvnDAaZHcgcHBMFl0EMamfACk2SRiouIADHn5BeHpYojAWHrcsU3BqphYANZxwQC+I4jjE4WOAIRhESSNTSUmFFAA1BsA3BMcybDKPflTTYI5AHRYACbXxaXrDBP92MNjOsEAnjAYetdGazMW104ymyVS5xI5Eo1CgiXE6GwuEWZAoVBo9CeCTQjgMfBgbTq20QBIUiAAjHUiSSto1wXADBc9HAAOZ0SGomEYi6UAAeUEYT3GQA)。

```typescript
function *createPrimeGenerator() {
  const primes = new Set<number>()

  let current = 2
  while (true) {
    while (true) {
      let isPrime = true
      for (const prime of primes) {
        if (current % prime === 0) {
          isPrime = false
          break
        }
      }

      if (!isPrime) {
        current++
        continue
      }

      primes.add(current)
      break
    }

    yield current++
  }
}

const primeGenerator = createPrimeGenerator()
for (let i = 0; i < 100; i++) {
  console.log(primeGenerator.next())
}
```

関数名の前に `*` をつけることでジェネレーター関数を定義できる。ジェネレーター関数はジェネレーター (`Generator`) を返し、その値は `yield` キーワードで生成される。利用者は `next()` をコールすることでジェネレーターに次の値を要求できる。

## ジェネレーターとイテレーター

`createPrimeGenerator()` が返す値はジェネレーターだが、イテレーターでもある。もっと言えば、反復可能なイテレーターでもある。

『プログラミングTypeScript』から「反復可能オブジェクト」と「イテレーター」の定義を引用しよう。

> **反復可能オブジェクト**: `Symbol.iterator` と呼ばれるプロパティを含んでいるオブジェクト。このプロパティの値は、イテレーターを返す関数。
>
> **イテレーター**: `next` と呼ばれるメソッドを定義しているオブジェクト。この `next` メソッドは `value` および `done` というプロパティを持つオブジェクトを返す。

ここで IDE (IntelliJ IDEA) は先ほどの例での `primeGenerator.` の補完を次のように表示してくる。

![IntelliJ IDEA が表示するジェネレーターの補完候補](/images/20230113-iterator.png)

`System.iterator` と `next` の両方を持つことがわかる。したがって、これは反復可能なイテレーターだと言える。


投稿記事