機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

k8s Deploymentのラベルの扱いについて

先日CKADを再取得した際、Deploymentのラベルの扱いについて再認識したことがあったので備忘メモを残しておきます。

一般的なDeploymentのラベル

よく見るDeploymentの例では、以下の例のようなラベル(★印)が定義されています。

例:controllers/nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx ←★任意:このリソース(Deployment)のラベル
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx ←★必須:Deploymentが管理するPodのラベル ・・・【A】
  template:
    metadata:
      labels:
        app: nginx ←★必須:このリソース(Deployment)配下のPodのラベル ・・・【B】
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

それぞれのラベルの意味はkubernetes公式ドキュメント Deployment | Kubernetes にも記載されており【任意/必須】も含めて上記のような役割を担っています。

apply時にエラーとなるパターン

必須の【A】と【B】は省略できず、例えば以下のようなパターンではapply時にエラーとなりリソースを生成できません。(A ⊈ B)

パターン① 【A】(未定義):.spec.selector の定義が存在しない
The Deployment "nginx-deployment" is invalid: 
* spec.selector: Required value
* spec.template.metadata.labels: Invalid value: map[string]string{"app":"nginx"}: `selector` does not match template `labels`
パターン② 【A】(未定義):.spec.selector の定義は存在するがラベルが未定義
The Deployment "nginx-deployment" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string(nil), MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: empty selector is invalid for deployment
パターン③ 【A】app: nginx 【B】(未定義):.spec.template.metadata.labels の定義は存在するがラベルが未定義
The Deployment "nginx-deployment" is invalid: spec.template.metadata.labels: Invalid value: map[string]string(nil): `selector` does not match template `labels`
パターン④ 【A】app: nginx 【B】app: xxxxx:.spec.template.metadata.labels の定義は存在するがラベルが不一致
The Deployment "nginx-deployment" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"xxxxx"}: `selector` does not match template `labels`

apply時にエラーとならないパターン

ラベルは複数定義できるため、厳密にすべてのラベルが完全に一致している必要があるかと言えばそうではありません。

以下のようなパターンはリソースを生成できます。(A ⊆ B)

パターン⑤ 【A】app: nginx 【B】app: nginx + age: fifty

定義:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
        age: fifty
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

をapplyすると以下のように問題なくリソース作成できます。

kubectl apply -f deploy.yaml 
deployment.apps/nginx-deployment created

kubectl get pods --show-labels 
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
nginx-deployment-7f5b4c8c69-k458q   1/1     Running   0          27s   age=fifty,app=nginx,pod-template-hash=7f5b4c8c69
nginx-deployment-7f5b4c8c69-kb6n2   1/1     Running   0          27s   age=fifty,app=nginx,pod-template-hash=7f5b4c8c69
nginx-deployment-7f5b4c8c69-vkrlh   1/1     Running   0          27s   age=fifty,app=nginx,pod-template-hash=7f5b4c8c69
パターン⑥ 【A】app: nginx 【B】app: xxxxx + app: yyyyy+ app: zzzzz+ app: nginx

※こんなことする人は居ないと思いますが試しにやってみました。(key重複は後勝ちなんですね😅)

定義:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: xxxxx
        app: yyyyy
        app: zzzzz
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

をapplyすると以下のように問題なくリソース作成できます。

kubectl apply -f deploy.yaml
deployment.apps/nginx-deployment created

kubectl get pods --show-labels 
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
nginx-deployment-647677fc66-8lrnr   1/1     Running   0          12s   app=nginx,pod-template-hash=647677fc66
nginx-deployment-647677fc66-gchpd   1/1     Running   0          12s   app=nginx,pod-template-hash=647677fc66
nginx-deployment-647677fc66-shcvh   1/1     Running   0          12s   app=nginx,pod-template-hash=647677fc66

所感

k8sのリソースまわりは公式ドキュメントなどを読んでもイマイチ正しく理解できたかいつもモヤモヤしてしまいます。 今回のように試験勉強でハマったり気になったりしたことは実際に手を動かしてコマンドを叩いて検証するのが一番スッキリしますし、 単に機械的に資格を取得するための学習だけをするのは非常にもったいないので、学びの機会として今後もうまく利用していきたいところです。

参考情報

今回は以下の情報を参考にさせてもらいました。🙇‍♂️

2025-04-25 Certified Kubernetes Application Developer (CKAD) を再取得しました【未だ四冠🥺】🐳🐳🐳🐳

直近またk8sのお仕事をすることになったのと Certified Kubernetes Security Specialist (CKS) の有効期限が切れる前に一度 Kubestronaut の称号(と限定ジャケット)をゲットしておきたかったので 認定Kubernetesアプリケーション開発者 (CKAD-JP) を再取得することにしました。結果としてはCKADを再取得することには成功したのですが、 Kubestronaut の称号を得ることには失敗しました。これまでの受験では発生しなかったトラブルが何度も発生したので、後学&備忘録として経緯を記録しておこうと思います。

 

Kubernetes認定資格

本日(2025年4月27日)時点ではLinux Foundationが認定するKubernetesの認定資格は、次の5種類(KCNA/KCSA/CKA/CKAD/CKS)があります。また、2024年3月から新たに Kubestronautプログラム なるものが開始されており、これら5種類を全冠した人に与えられる新たな称号です。k8sエンジニアのコレクター心理をくすぐるいやらしい戦略ですね(笑)

今回、改めて認定有効期間の最新動向を調べてみましたが昨年アナウンスされた

2024 年認定有効期限ポリシーの変更 - Linux Foundation - トレーニング

2024年4月1日から全ての認定期間が24ヶ月(2年)に変更されている点 から変更はありませんでした。

そして、ご存じの通り認定試験の価格も順調に値上げされており、このようなアナウンスがでておりました。(ま、これはいつものことですね…💸)

2025年2月4日よりCKA、CKAD、CKS、LFCS 認定試験の価格変更のお知らせ - The Linux Foundation

略称 正式名 概要

KCNA

KCNA-JP

  • Kubernetes and Cloud Native Associate(KCNA)
  • 認定Kubernetesクラウドネイティブアソシエイト(KCNA-JP)
Kubernetesと広範なクラウド ネイティブ エコシステムに関する基本的な知識とスキルを証明する(有効認定期間:2年間

KCSA

  • Kubernetes and Cloud Native Security Associate(KCSA)
  • 認定Kubernetesクラウドネイティブセキュリティアソシエイト (KCSA)
Kubernetesクラスタのベースラインセキュリティ設定を理解し、セキュリティ制御の強化/テストと監視/脅威と脆弱性の強化に参加し、コンプライアンス目標を達成できるスキルを証明します(有効認定期間:2年間

CKA

CKA-JP

  • Certified Kubernetes Administrator (CKA)
  • 認定Kubernetes管理者  (CKA-JP)
Kubernetes管理者の責任を遂行するスキル、知識、および能力を備えていることを保証する(有効認定期間:2年間

CKAD

CKAD-JP

  • Certified Kubernetes Application Developer (CKAD)
  • 認定Kubernetesアプリケーション開発者 (CKAD-JP)
ユーザーが Kubernetes 用のクラウドネイティブ アプリケーションを設計、構築、デプロイできることを証明する(有効認定期間:2年間

CKS

CKS-JP

  • Certified Kubernetes Security Specialist (CKS)
  • 認定Kubernetesセキュリティスペシャリスト (CKS-JP)
Kubernetesの熟練した実践者(CKA認定が必要)であり、コンテナベースのアプリケーションやKubernetesプラットフォームの構築、デプロイ、ランタイム時のセキュリティを確保するための幅広いベストプラクティス能力を実証する(有効認定期間:2年間

 

試験対策

今回の試験対策で実践した内容は主に次の2つです。 

1.Udemy

2019年に購入した教材を再利用したので今回新たに教材を購入しませんでした。なんと嬉しいことに最新動向に追従して教材がちゃんとアップデートされていました。これはありがたいですね。

Kubernetes Certified Application Developer (CKAD) Training | Udemy

主に以下の模擬試験的な教材を中心に実際に手を動かして繰り返し復習しました。

  • セクション12: Mock Exams
  • セクション11: Lightning Labs

セクション12→11の順に実施する理由は、セクション11の方が難易度が高いためです。こちらの過去記事にも記載していますので併せてご覧ください。

2.Killer Shell - Exam Simulators

試験を申し込むと教材として利用できるようになります。

Killer Shell - Exam Simulators

主に以下の模擬試験的な教材を中心に実際に手を動かして繰り返し復習しました。

* CKAD Simulator Kubernetes 1.32

こちらの教材には有効期限があるので模擬試験として利用する場合はタイミングを考慮して利用しましょう。ただ、模擬試験として利用する有効期限が過ぎても解答と解説は閲覧することができます。目的に応じてうまく活用しましょう。

 

受験時のトラブルの経緯

今回の受験で実際に起きたことを時系列に沿って記載すると以下のような感じです。

# 日時 事象

1

2025年04月06日(日)

10:00~10:30

★ 受験(1回目):無効

試験開始後30分で PSI Secure Browser がフリーズして試験が強制終了する

2

2025年04月06日(日)

10:36

終了後すぐに

http://trainingsupport.linuxfoundation.org/

でサポートへチケットを起票する

3

2025年04月08日(火)

20:32

採点中(Grading in progress)のまま48時間以上経過してもサポートから回答がないので起票したチケットにコメントを追記する

4

2025年04月09日(水)

12:10

採点中(Grading in progress)のまま72時間以上経過してもサポートから回答がないので起票したチケットにコメントを追記する
5

2025年04月09日(水)

17:52

サポートから再度受験が可能となった旨の連絡がくる
6

2025年04月11日(金)

04:00~04:30

★ 受験(2回目):無効

事前にPCスペックやネットワーク帯域などを入念にチェックして試験に臨むも再び試験開始後30分で PSI Secure Browser がフリーズして試験が強制終了する

7

2025年04月11日(金)

10:20

終了後しばらく様子を見つつ

http://trainingsupport.linuxfoundation.org/

でサポートへチケットを起票する

8

2025年04月16日(水)

23:13

採点中(Grading in progress)のまま1週間近く経過してもサポートから回答がないので起票したチケットにコメントを追記する
9

2025年04月17日(木)

00:00

CKSの資格を失効する(このタイミングで Kubestronaut になる資格を喪失する)

10

2025年04月17日(木)

18:44

あまりにもサポートから回答がないので心配になって起票したチケットに更に催促のコメントを追記する
11

2025年04月17日(木)

19:47

サポートから再度受験が可能となった旨の連絡がくる
12

2025年04月20日(日)

16:00~18:00

★ 受験(3回目):不合格

受験時に使用するPCを再セットアップ(OS再インストール)して受験したところ PSI Secure Browser がフリーズすることなく受験が完了する(試験結果は不合格だったが、最後まで受験できたことに安心する)

13

2025年04月25日(金)

04:30~06:30

☆ 受験(4回目):合格

PSI Secure Browser がフリーズすることなく受験が完了する

今回のトラブルに対処するためネットに有益な情報がないか検索(例:PSI Secure Browser、フリーズ、など)してみたところ、数は多くはないものの、似たような事象で困っている人は一定数いそうでした。

いずれも、これといった有効な解決策はないようで、とにかく気長にサポートとキャッチボールをしながら、受験する環境を変えて原因の切り分けをするというアプローチしか無さそうです。(こうなると試験センターで受験するという選択肢も欲しいですね)

 

受験時のトラブルの教訓

1.計画について

今回は初回受験から受験終了まで20日(3週間弱)を要しました。目論見としては、CKSの資格を失効する2025年4月17日(木)までに、ギリギリ2回(初回受験+リテイク)受験して合格するというスケジュールで臨んだのですが完全に計画が破綻してしまいました。これまでの受験では今回のようなトラブルには遭遇したことがなかったので、まさかここまで時間がかかるとは想像もしていませんでしたが、今後は今回のようなトラブルが発生することも念頭に置きながら計画を立てて臨む必要があると痛感しました。加えて、サポートとのキャッチボールのリードタイムも想像より長い印象でした。特に2回目フリーズ時は催促して1週間くらいだったので、もし強めの催促をしなかったらもっと放置された可能性も高かったように思います。

2.環境について

なるべく今回のようなトラブルに遭遇したくなかったので、過去に受験で使用した実績のあるPCを利用して受験に臨んだのですが、残念なトラブルに見舞われてしまいました。最終的にPCを再セットアップ(OS再インストール)して受験することで試験を完了させることができたので、少なくともネットワーク帯域やH/Wの問題ではなく、OSにインストールされている何らかのソフトウェアが影響していた可能性が高いことまでは分りましたが詳細は不明です。試験センターで受験できないスタイルの資格試験なので、難しいとは思いますが受験前のシステムチェックなどでもう少し厳密にチェックして事前に教えてほしいところです。

 

試験時の注意点

今回は基本的には問題文を日本語の表示で受験しましたが、途中明らかにおかしな問題文があり、英語の表示に切り替えたところ、問題文の原文(英語)の多くが無視され欠落した意味の分からない問題がありました。問題文のタグ名が

undefined: undefined

と明らかに不自然な表示になっていたので気付けましたが、自動翻訳の怖いところです。多言語対応しているとはいえ、翻訳後の問題文のチェックはあまりされていない前提で試験に臨むのが良さそうです。

 

さいごに

結局今回は Kubestronaut になることはできませんでした。CKSを再取得するモチベーションが湧けば改めて挑戦したいと思いますが、なかなか手間もお金もかかることなのでもう少し考えてから決めたいと思います。それでは一旦お疲れさまでした🙇‍♂️

*[本]「OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本」: [2024改訂]

こちらも先日の技書博で購入した本です。

前回記事の前に読んだ本なのですが、こちらについても学びのメモを残しておきます。

techbookfest.org

本書の構成

  • はじめに
  • 第1章 本書の狙いと構成
  • 第2章 OAuth 復習
  • 第3章 OAuth 認証
  • 第4章 OpenID Connect
  • 第5章 チュートリアル
  • あとがき

印象に残った点

個人的に参考になったと感じた点について以下に簡単にまとめておきます。

はじめに

本書の用語の定義

用語 説明
OAuth OAuth2.0 のこと
OAuth の仕様 RFC6749 のこと
OIDC の仕様 OpenID Connect Core 1.0 のこと

第1章 本書の狙いと構成

以下の3点の意味を理解できていること

  • OAuth は権限委譲のプロトコル
  • 「OAuth 認証」と呼ばれるものはプロフィールAPIによる認証
  • OpenID Connect は IDトークンによる認証

第2章 OAuth 復習

2.1 OAuth とは何か【P.10】

OAuth は権限委譲のプロトコルです。 認可のプロトコルとも言われます。 OAuth によって、ユーザーのリソースへのアクセス権限をサードパーティのアプリに委譲できます。 しかも、サードパーティアプリにはリソースオーナーのID・パスワードを教える必要はありません。

2.5 グラントタイプ【P.14】

OAuth 2.0のグラントタイプ(Authorization Grant)には4種類のグラントタイプ(※OIDCではフローと呼ぶ)がある。

  1. 認可コード(Authorization Code
  2. インプリシット(Implicit
  3. リソースオーナーパスワード(Resource Owner Password Credentials
  4. クライアントクレデンシャル(Client Credentials

本書ではOAuth 認証とOIDC(OpenID Connect)に関係する前者2つのグラントタイプ(認可コード、インプリシット)について解説している。

第3章 OAuth 認証

3.1 認証のため(の?)プロトコルという勘違い【P.17】

OAuth は権限委譲のためのプロトコルです。 (中略) ここには「アプリへのログインのためにユーザーを認証する」という話は出てきません。 OAuth はアプリの認証のためのプロトコルではないからです。 話がややこしいのはリソースサーバーとしてプロフィール情報を提供するAPIがある場合です。 本書では以降、このようなAPIを「プロフィールAPI」と呼びます。 アプリはこのプロフィールAPIで得たユーザー識別子の情報などを利用して、ユーザーの認証が可能になります。 これがいわゆる「OAuth 認証」です。

第4章 OpenID Connect

4.1 OpenID Connect とは何か【P.35】

仕組みの視点においては以下のとおり。

【OIDC】=【OAuth】+【IDトークン】+【UserInfoエンドポイント】

4.2 OAuth と OIDC の違い

4.2.1 ロール関連用語の違い【P.36-38】

OAuth と OIDC で用語が異なることに加え、OIDC でも複数の呼び方が混在していてややこしい。🥺

対象 OAuth OIDC
利用者 リソースオーナー エンドユーザー
アプリ クライアント リライング・パーティ
トークン発行 認可サーバー IDプロバイダ / オープンIDプロバイダ
(IdP:Identity Provider/OP:OpenID Provider)
情報取得 リソースサーバー
(様々なリソース)
UserInfoエンドポイント
(プロフィール情報のみ)

4.2.2 その他の違い

■ グラントタイプ / フロー【P.38-39】

OAuth では「グラントタイプ」と呼んでいたものは、OIDC では「フロー」と呼ぶ。

「グラントタイプ」と「フロー」の対応は以下のとおり。

グラントタイプ / フロー OAuth OIDC
認可コード ◯:あり ◯:あり
インプリシット ◯:あり ◯:あり
リソースオーナーパスワード ◯:あり X:なし
クライアントクレデンシャル ◯:あり X:なし
ハイブリッド ◯:あり ◯:あり
■ シーケンス【P.42-43】

つきつめると、OAuth と OIDC のシーケンスの違いは IDトークン の発行の有無と言っても過言ではない。

4.3 IDトークン

4.3.1 IDトークンとは【P.43】

OAuth 認証では、プロフィールAPIの情報でエンドユーザーの認証をする。

OIDC では、IDトークンでエンドユーザーの認証をする。

IDトークンの形式は、署名付きの JWT(JSON Web Token:ジョット)です。

4.5.5 OIDC が OAuth の拡張仕様である意味【P.80】

OIDC は OAuth の仕様を認証で利用できるように拡張したもの。

 コラム:OpenID Connect は OAuth の拡張だが、OAuth ができてから仕様策定が始まったわけではない【P.86】

途中までそれぞれの団体(OAuth1.0:IETF と OpenID2.0:OpenID Foundation)により策定されていたプロトコルが

  • JSON 、RESTを使うという設計方針が共通している
  • UserInfoエンドポイントへのアクセス制御は OAuth2.0 で定義される仕組みと機能が重複している

といった状況が見えてきた段階で両者が合流、協力しながら進めることになった。

気になったこと

第3章のコラム(P.33)で

「OAuth 認証」という言葉はなぜ使わないほうがよいのか

で、

本書では「OAuth + プロフィールAPI」による認証を「OAuth 認証」と呼んでいますが、「OAuth 認証」を規定した仕様があるわけではありません。すなわち「OAuth 認証」の定義があるわけではなく、皆が好き勝手に「OAuth 認証」という言葉を使っているにすぎません。

(中略)

不用意な誤解が広がるのを防ぐために、読者のみなさんも「OAuth 認証」という言葉はできるだけ使わないようにしましょう。

と記載されているのですが、こちらの本の中では使われまくっていたのが気になりました。

できれば本書の中で体現してほしかったなと感じましたが、もしかしたら、書き上げた後で気づいてコラムを追加したのかもしれないですね。

実践:雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本

先日の技書博で購入した本をハンズオンしてみました。

techbookfest.org

やったこと

Githubに実践メモを残したのでこちらをご参照ください。

github.com

おまけ

偽書博ではシリーズ3冊まとめて購入しました。

左の2冊は既読ですが右の1冊はまだ積読状態なので後ほど読みたいと思います。

ちなみに、まとめ買いしたらこんなステッカーもセットでいただきました。どこに貼ればよいのだろうか…

*[本]「世界はなぜ地獄になるのか」

近所の図書館へ別の本を借りに行ったら気になって手に取って読んでみました。

www.shogakukan.co.jp

読んでみて印象に残った点を中心に以下に書き留めておきます。(返却前メモ)

本書の構成

本の構成は、下記のような章立てになっています。

<構成>
はじめに

■PART1 小山田圭吾炎上事件

PART2 ポリコレと言葉づかい

PART3 会田誠キャンセル騒動

PART4 評判格差社会のステイタスゲーム

PART5 社会正義の奇妙な理論

PART6 「大衆の狂気」を生き延びる

あとがき ユーディストピアにようこそ

印象に残った点

印象に残ったフレーズや共感できた点などを以下にメモしておきます。

PART4 評判格差社会のステイタスゲーム

ステイタスを感知する超高精度のソシオメーター

【Page:141】

"(前略)わたしたちは、自分よりステイタスの高い者と比べときに痛みを、ステイタスの低い者と比べるときに快感を覚える。これは脳の基本設計なので、心がけや道徳教育で変わるわけではない。立派なことばかりいっている宗教家でも、ヒトである以上、みなこの不都合なOS(オペレーティングシステム)を埋め込まれている。

 生き物は、苦痛や嫌悪を避け、心地よいものに向かうように進化してきた。だとしたらわたしたちも、上方比較を避け、下方比較を好むような選択・行動を(無意識のうちに)しているはずだ。"

自尊心を守るための陰謀論

【Page:156】

"(前略)このようなとき、ほとんどのひとは、過去の自分の主張が誤っていたと認めることはできない。アイデンティティ(アメリカ人としての誇り)を否定してしまえば、生きる意味がなくなってしまう。これはとてつもない恐怖に違いない。

 自分が正しいと信じていたことがじつは間違っていたときに生じるのが「認知的不協和」で、こうした場面に遭遇すると、わたしたちは無意識のうちに話しのつじつまを合わせようとする。この衝動はきわめて強いため、進化心理学者のロバート・トリヴァースは、「知能の進化的な役割は自己正当化である」と述べた。

 Qアノンの陰謀論を信じるひとたちの奇矯な行動は、ある意味、きわめて合理的だ。

 仕事も、評判も、プライドもなにもかも失った白人が、かつてあれほどバカにしていた黒人と同じ立場になったことに気づいたとき、「(大学に行かなかった)自分が悪い」などと思えるわけがない。自分に責任がないとすれば、なんらかの「悪」によって現在の理不尽な状況に追いやられたにちがいない。それは政治の失敗や資本主義の暴走のような「凡庸な悪」ではなく、とてつもない「絶対悪」でなければならない。なぜなら、それと戦う自分が「絶対善」になれるから。"

死ぬまで続く残酷なゲーム

【Page:160】

"上方比較を損失、下方比較を報酬とする脳は、ステイタスの高い者を「正義」の名の下に引きずり下ろすときに、きわめて大きな快感を得る。"

【Page:161】

"わたしたちはステイタスの高い者に憧れながら、ステイタスの高い者を引きずり下ろそうとし、他者からの批判を過剰に気にして身を守りながら、ライバルの足を引っ張って自分のステイタスをすこしでも高めようとあがいているのだ。"

【Page:162】

"こうして、ステイタスゲームに翻弄されてストレスで擦り切れる(定型発達の)「健常者」よりも、他者の評価をさほど気にしない(非定型発達の)ASD(自閉症スペクトラム)の「障害者」の方が、現代のSNS社会に適応しているのではないかといわれるようになった。"

PART6 「大衆の狂気」を生き延びる

他者とのコミュニケーションから撤退する

【Page:248】

"道を歩いているだけで、いつ誰から殴りかかられるかわからないような世界はものすごく不安にちがいない。だからこそ人類は、さまざまな方法で暴力を管理・抑制しようとしてきた。

 だが皮肉なことに、それによってわたしたちは、いつ「加害者」と名指しされ、バッシングされるかわからない世界を生きることになった。言葉の暴力は、客観的には身体的な暴力よりはずっとマシだろうが、主観的には、不安の程度はほとんど変わらない(脳は身体的な暴力と言葉の暴力を区別できない)。

双方が合意できる基準がない以上、「加害者」と糾弾された者は、自分のことを理不尽な暴力(大衆の狂気)にさらされた「被害者」だと訴えるだろう。このようにして、双方の憎悪だけがだかまっていく。"

「極端な人」に絡まれないためには

【Page:263-264】

"(前略)SNSの炎上を研究する山口真一(ネットメディア論、情報経済論)は、炎上に勝たんするのは「男性」「世帯年収が高い」「主任・係長クラス以上」という属性の持ち主だという。仕事が忙しくても、同居する家族がいても、2時間もあれば数百件は書き込めてしまうから、「暇人」である必要はないのだ。"

【Page:265】

"自分の身を守る方法た、リアルでもバーチャル(ネット)でも同じだ。もっとも重要なのは、こういう「極端な人」に絡まれないこと。そのための最低限の原則は、「個人を批判しない」だ。なぜならこのひとたちは、自分が批判されたと思うと、常軌を逸して攻撃的になるから。自分が「被害者」で、なおかつ「正義」だと信じている相手に対しては、ほぼ打つ手はない。

 それでもあなたの発言に不愉快なコメントをする者はいるだとう。そのときは、ただ無視するか、ブロックする。「批判されたら反論しなければならない」と思っているひともいるようだが、これは最悪の対応だ。「極端な人」は、自分に対するどのような反論も、善と悪との戦いにしてしまう。あなたは「悪」のレッテルを貼られ、泥沼に引きずり込まれることになる。"

【Page:269】

"ウィル・ストーは『ステータス・ゲームの心理学』でこう書いている。

キリスト教徒は地獄をつくりだすことによって救済への不安を生み、それから逃れられる唯一の方法として自分たちのゲームを提示した。同じように、新左翼の活動家たちは、偏見だと非難してもよい条件を根本的に書き直し、単に白人や男性であることが罪の兆候になるようにハードルを下げることで地獄をちらつかせる。こうして救済への不安を生みだしたうえで、自分たちの運動を唯一の救済策として提示するのだ。地獄の脅威から逃れるためには、これみよがしに熱心に、非常に正しくプレーをするしかないのだと。

あとがき

ディストピアへようこそ

【Page:275】

"(前略)だがますます複雑化する社会で、すべての理想を叶える魔法のような政治制度は存在しない。だからこそ、誰もが不安を抱えつつも、ほどほどのところで妥協するしかない。これが「寛容」と「中庸」だ。

 これは要するに、「あなたが生きているリベラルな社会は、人類史的には(とりわけあなたが先進国に生まれたのなら)とてつもなく恵まれているのだから、実現不可能な理想を振りかざしていたずらに社会を混乱させるのではなく、いまの自分に満足し、小さな改善を積み重ねていきなさい」という提言だ。

 ここで、「そんな説教臭い話を聞きたいわけじゃない」と思ったかもしれない。だが、フクヤマがあえて寛容などという当たり前の(凡庸な)ことを主張したのは、すくなくとも現時点では、これ以外の解が存在しないからだ。"

【Page:276】

"アメリカ最高裁は2023年6月、ハーバード大などが人種を考慮した入学選考をすることを違憲と判断した。裁判で開示された資料では、アジア系の学生がハーバードに入学するためには、2400点満点のSAT(大学入学のための標準テスト)ではくじにより140点、ヒスパニックより270点、黒人より450点高い点数を取る必要がある。最高裁はこれを、近代社会の原則である市民の平等に反すると結論した。"

[2025/1/25(土)]第十一回 技術書同人誌博覧会@横浜へ参加してきました #技書博

第十一回 技術書同人誌博覧会@横浜産貿ホール マリネリア に参加してきました。

gishohaku.dev

技術書典は過去に参加したことがありリアル参加した後も時々オンラインでイベントに参加して良さげな技術書を買い漁ったりしていましたが、技術書同人誌博覧会(以降は「技書博」と呼びます)は今回が初参加でした。

技書博は技術書典と何が違う?

違いが分からなかったので調べてみました。以下のような違いがあるようです。

技術書同人誌博覧会(技書博)

技術に関する同人誌の即売会です。ITの他に、理工/数学/デザイン/マネジメントなど幅広い技術を取り扱っています。エンジニアのアウトプットを応援したい&増やしたいという思いからこのイベントが生まれました。初心者にもベテランにも優しく、ゆったりと交流しながら知識を深め、仲間を作ったり成長できるような場所を目指しています。(引用元:技術書同人誌博覧会、詳細はコチラ→ 技書博ってなに? - 技書博公式ブログ

技術書典

ITや機械工作とその周辺領域について書いた本を対象にした同人誌即売会。技術者たちの「コミケ」とも言われる。運営はテックベース合同会社。(引用元:技術書典 - Wikipedia

イベント参加方法

今回の会場は横浜産貿ホールマリネリアでした。毎回同じ場所ではないので注意してください。またイベントに参加するには事前登録が必要となりますので併せてご注意ください。入口のイベント受付でスマホ画面でconnpassの受付票を見せて入場します。

会場内の各ブースでは様々な技術書が展示されており立ち読みはもちろん著者や売り子の方と会話しながら好みの本を選んで買うことができます。ネットや本屋で本を購入するのとはまた違った本との出会いがとても良き感じでした。

謎のトライアル企画 🍵

技書博イベントと同じフロアの一角で謎の茶会が開催されていました。完全に別のイベントだと思いスルーしていたのですが、これも技書博の企画の一環で、無料でお抹茶とお菓子がいただけました。どちらもとても美味しかったです。ごちそうさまでした🙇

絶対に偶然だと思いますがお茶の表面模様が猫の肉球みたいでキュンキュンしました😻

また茶会の受付では、くじ引きをやっており、めでたく3等賞が当たりました。🎯

景品として名言バッジ「本はのみ物」をちょうだいしました。併せてありがとうございます🙇

blog.gishohaku.dev

イベントの戦利品

また積読が増えました。たぶん積読は一生なくならないと思います(笑)
しかし、これでいい、、、これでこそ積読。積読だっ。ざわ…ざわ…ざわ…

おまけ

今回の技書博の中でも販売していましたが、私もほんの少しだけ寄稿させていただいた書籍「みんなのアジャイル」が先週末1/24[金]に技術評論社さんから発売されました。ご興味のある方はお手にとっていただけると嬉しいです。

gihyo.jp

最後まで読んでいただきどうもありがとうございました。

*[本]「地図が語る感染症の歴史」: Atlas historique des diocèses

近所の図書館へ別の本を借りに行ったら気になって手に取って読んでみました。

books.rakuten.co.jp

読んでみて印象に残った点を中心に以下に書き留めておきます。(返却前メモ)

本書の構成

本の構成は、下記のような章立てになっています。

<構成>
序文
6 感染症と場所
■パンデミックの惑星
12 新石器革命の毒入りギフト
16 古代の疫病
20 中世における黒死病
23 コロンブス交換、微生物の交差
26 蚊の帝国
29 コレラーー現代の感染症の原型
32 スペイン風邪の衝撃
35 根絶の夢
39 エイズー幻想の終焉

■感染症の探索者ーー疫学の視覚文化
44 悪い空気
48 症例をカウントする
51 地図の魔法
54 流行曲線
57 ネットワークとクラスター
61 ウイルスの追跡ーー遺伝子配列の貢献

■流行の領域ーー政治地理学的考察
66 地中海における検疫と交易
69 コレラと帝国の時代における検疫
72 植民都市における感染症と人種隔離
75 東ヨーロッパにおける戦争、ナチおよびチフス
79 アフリカにおける眠り病との植民地戦
82 国際開発問題としての感染症
86 グローバル安全保障問題としての感染症
89 新型コロナ禍での世界のロックダウン

■ロックダウンの場ーー監禁から自己の発見へ
94 サナトリウムにおける近代的生活
97 衛生学者のユートピア
100 ハンセン病施療院列島
103 隔離された生活ーーニューヨークのチフスのメアリー
106 パリのクロード=ベルナール感染症病院
109 出会いの場、管理の場
112 ニューヨークとパリ、エイズの都
115 感染症と語り

■病原性の環境
120 中央アフリカにおけるHIVの環境史
123 生物多様性の危機と感染症の危機、20世紀と21世紀
126 脱工業化社会の感染症
129 環境病としてのライム病
132 感染症と交差性ーーイル=ド=フランスの例
135 感染症の傷ーートラウマと記憶

おわりに
138 感染症を別のアプローチで

印象に残った点

印象に残ったフレーズや共感できた点などを以下にメモしておきます。

パンデミックの惑星

新石器革命の毒入りギフト

【Page:13】

"ジャレド・ダイアモンドの言葉をかりれば、感染症は「家畜からの致命的な贈り物」なのである。"

より広範な生態系の変遷

【Page:13-14】

"しかし、感染症は家畜化だけがもたらした悲劇的な結果ではない。動物への曝露(疾病や健康状態の原因と推定されるものに生体がさらされること)以上に、都市化が決定的な要因である。理論的には、麻疹ウイルスのように感染力が非常に強く、生存者に強い免疫力を生み出すウイルスは、感染する可能性がある対象者、つまり一度も曝露したことのない人々が十分にいるという条件でのみ、人間集団の中で存続することができる。"

根絶の夢

期待はずれの根絶計画

【Page:36】

"世界保健機関(WHO)は、薬剤治療やワクチン接種によって、媒介昆虫や病原体を標的にした根絶キャンペーンを数多く展開してきた。これらのキャンペーンのほとんどは失敗に終わっている。1980年に宣言された天然痘の根絶は、唯一の傑出した成功例であり、これは、2世紀にわたって使用されてきたワクチンの単純さと、動物病原巣をもたず無症候性感染を引き起こさない理想的な標的であるウイルスの生物学的特性とに負うところが大きい。"