dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

CursorでWebアプリ個人開発メモ Day2:.cursorrulesからProject Rulesへの移行

前回:
CursorでWebアプリ個人開発メモ Day1:要件定義と技術選定 - dackdive's blog

前回、要件定義の最中に開発ルールを .cursorrules に記述するというのもやっていたのだが、
現在は Project Rules という指定のしかたのほうが推奨されているということを知った。

せっかくなのでこの移行も Cursor にやらせてみる。

.cursorrules から Project Rules へ

@ からはじまる Symbols 機能を使う。
雰囲気で @Web のあとに Cursor 公式ドキュメントへのリンクを載せた。
が、 @Web は文字通り Web 検索する機能なので、今回の用途だと @Link だったぽい。

うーん、元々 .cursorrules にはコミットメッセージに関するルールと開発プロセスに関するルールをセクション分けて書いてたので、ファイルも分割してほしいな。
あとディレクトリって .cursor/rules じゃないの?

ファイル分割してーって言ったらディレクトリも正しくなった。
よさそう。と思ったけど今度は拡張子が怪しい。

コマンドパレットの

File: New Cursor Rule

で作成すると、拡張子は .mdc になる。 https://docs.cursor.com/context/rules-for-ai に明記はされてないけど、キャプチャのファイル拡張子も .mdc。

平然と嘘をつく。

直った。

今日の学び

Project Rules を知る。ついでに Symbols 機能をちょっとだけ使う。

今日のコスト

確認し忘れた(別の作業も直後にやってた)

CursorでWebアプリ個人開発メモ Day1:要件定義と技術選定

Devin の記事とか読んで自分も手を動かさないとだめだと思ったので、個人開発でちょっとずつ試してみることにする。
Devin は個人で契約するには厳しいので Cursor を使ってみる。

Cline を一瞬試していたのだが、併用する DeepSeek がセキュリティ上懸念がありそうで(個人開発なら別にいいけど)
そうすると Cursor の代わりに Cline + LLM の何か、をわざわざ選択する理由があまり浮かばず
まずは Cursor に慣れることにした。

前提

Cursor は $20/月の Pro プラン を契約する。
また、Yolo モードを有効にして git, npm あたりのコマンドを許可しておく。

基本的に Composer の agent モードで動かしている。

進捗はここのリポジトリで管理する。

要件定義

Cursor を使って何作ろうかなと考えた結果、なんとなく前から作りたいと思ってたアプリを題材にすることにした。
が、詳細な要件を自分で考えるのも面倒なので、そもそもの要件を言語化するところから依頼した。

とあるWebアプリケーションを開発したいです。 まず、要件定義から一緒に始めましょう。なお、ここで決まったことはdocs/spec.mdとしてドキュメントに残すことにします。

その後、指示通りファイルを作ってくれて、質問に答えながら要件定義書っぽいドキュメントが作成されていく。

技術スタックの選定

要件がなんとなくわかったので、次は技術スタックを決めたい。ここも Cursor に相談する。

だいたいいい感じかなー。Remix とか shadcn/ui を使ってみたいですという注文をつける。
また、DB やホスティング先のサービス選定については、いくつかの選択肢から比較検討したい。
ので、ADR(Architecture Decision Record)を書いたうえで決定しませんかとお願いしてみる。

Cursor が提案してくれたものに「AWS だったらどうです?」みたいな選択肢を追加しつつ、一旦 Supabase と Fly.io でいくことに決める。また画像の保存先は Cloudinary がいいらしい。

これらの意思決定は docs/adrs/ 配下 に残しておく。

※決めたあとで、全部 Cloudflare のサービスでできないか?と思った。今度相談してみる

タスク管理ファイル(todo.md)の作成

技術選定が終わったら、向こうから「こんな感じで進めましょうか」という提案があった。
これを todo.md としてリポジトリで管理しながら進めることにする。

Remix プロジェクトのセットアップ

TODO の1個目にあった Remix プロジェクトの作成をやってもらう。
ここも基本的には提案されたコマンドを実行する、もしくは勝手に実行するのを眺めているだけ。

最初なんか存在しないテンプレを使おうとして失敗してるが自分で軌道修正してた。

プロジェクトの雛形ができあがったあとで、少し難易度高そうな注文をする。

依存ライブラリを極力減らしたいので、ESLintではなくBiomeを使いたいです

これはしばらく一人で試行錯誤してた。

なぜか古いバージョンの Biome を入れて解決しようとしてたので、そこは最後に指摘する。

.cursorrules の作成

これは実際には Biome のバージョン変更ではなく ESLint → Biome への移行が差分に含まれる。
あとさっきまで英語でコミットしてくれてたのに急に日本語になる。

コミットメッセージは今までと同じように英語でお願いします。 また、今後も同様なのでcursorrulesに書いておきたいです

これで一度 docs/cursorrules.md にファイルを作り始めたんだけど違う違う .cursorrules だよっつって直させる。

作業ログも残す

作業した内容と、Cursor を使って作業したふりかえりをログとして残せるといいかなと思い提案してみる。

私の所感ではなく Cursor の所感を勝手に書かれたので違うそうじゃないと訂正。

これで今日のところは終わり。

今日のコスト

Cline の、セッションごとにコスト表示してくれるやつ好きだったな。

わからないこと

「システム障害対応の教科書」を読んだ

読んだ。

本書の目次

第1章◆システム障害対応を学ぶ意義
第2章◆システム障害の定義
第3章◆システム障害対応の登場人物と役割
第4章◆各プロセスの基本動作~発生から終息まで
第5章◆障害対応に必要なドキュメント
第6章◆システム障害対応力を高めるツールと環境
第7章◆組織の障害対応レベル向上と体制作り
第8章◆システム障害対応力の改善と教育
第9章◆教育と育成の手引き
第10章◆障害対応訓練の実施
第11章◆事故を防ぐ手順書の作り方
第12章◆エンドユーザ向けの情報発信
Appendix◆難易度の高いシステム障害ケース

感想

システム障害対応に必要となる知識について、プロセスだけでなく体制作りや育成まで網羅的にカバーされており、まさに「教科書」といった感じだった。
私がそうだったが、通読しなくてもまずは興味があるところだけ読み、残りは必要になったときに参照するでもいいと思う。

とりあえず障害対応って何したらいいの?という人は第2章〜第4章とあとは第5章の「5.1 障害対応フロー図」「5.3 障害レベル管理表」あたりを読むのがオススメ。そこから発展して組織の障害対応の練度を上げる、みたいなことを考える必要が生じたときには第7章〜第9章あたりが参考になりそう。

個人的には第11章(手順書の作り方)、第12章(ユーザ向けの情報発信)が気になるトピックだった。が、これらは文量としてはそこまで多くなく、さらっとした内容だった。残念。

個人的に一番良かったのはこの図。

(p.35 より引用)

システム障害対応に関連するプロセスを上の図のように整理しており、かつシステム障害対応は「検知・事象の確認」〜「復旧対応」までとしている。
「本格(恒久)対策」以降を含まないのは、本書ではシステム障害対応の目的を「ユーザの業務影響を極小化し、早期に業務を復旧させること(p. 34)」と定義しているため。

この図の各ステップでやるべきことを理解した上で、実際の対応時は今この図のどのステップにいるのかを意識しながら作業を進めるのが良さそう。

気に入った一節

(参考:技術書は気に入った一節を見つけるだけでいい

システム障害対応の目的は、システムを直すことではありません。ユーザの業務影響を極小化し、早期に業務を復旧させること。これがシステム障害対応の目的です。システムを直すことは、業務回復の手段の1つであり、目的ではないのです。(p.34)

「2.2.1・システムを直す≠障害対応」より。 エンジニア脳だと、どうしても障害が発生すると原因を突き止めて解決しようというマインドになりがちだが、障害対応における目的はそうじゃないよ、と。

内容メモ

第2章 システム障害の定義

  • なぜシステム障害の定義が必要か?→それがシステム障害対応プロセスを開始するトリガーの定義にもなるから
  • 本書におけるシステム障害の定義

    リリース後のシステムにおいて、システムの不具合やユーザ側の操作ミスで、ユーザ業務に影響が出ている。もしくは出るおそれがあるもの

  • Point:ユーザ業務に影響がなくてもシステム障害と定義する
    • 影響が出る可能性がある時点で、すべてシステム障害として扱いプロセスを開始すべき
  • Point:システム提供者側に責任がない場合もシステム障害と定義する
    • 例えば、認証基盤にSaaSを使っていてそこの障害が発生した場合とか
  • 2.2.1・システムを直す≠障害対応
    • 「気に入った一節」に書いたやつ。だいじ
  • 2.2.4 主要なマネジメントフレームワークの概要
    • ITILでもインシデント管理と問題管理を分けてるのね

第3章 システム障害対応の登場人物と役割

  • インシデントコマンダーの役割
    • 作業担当者への指示
    • 必要な人員を集め体制を構築する
    • 顧客や関連チームとのコミュニケーション窓口になる
    • 障害の発生と終息の宣言
    • 情報の整理・記録と更新
      • 事象、発生日時、影響範囲、etc.
    • ...
  • Point:インシデントコマンダー担当を固定化させない
    • 組織上の上長が常に担うのはアンチパターン
      • 上長は不在なことが多い
      • 部下の成長が止まる
      • 上長が能力を持っているとは限らない
    • インシデントコマンダーは組織上の上下関係によらず誰でもなって良い。育成方法は9章

第4章 各プロセスの基本動作〜発生から終息まで

  • 4.1 検知・事象の確認
  • 4.2 業務影響調査

    業務影響の確認は、ユーザ視点・業務視点で行う必要があります

    • 影響調査を疎かにしがちな場合は、影響調査担当(チーム)を作る
      • エンジニアは原因追及や復旧に注力してしまいがち
    • 影響あり/影響なし/調査中、を漏れなく伝える

第5章 障害対応に必要なドキュメント

  • 5.1 障害対応フロー図
    • ぱっと流れを掴むためにフロー図欲しくなるのはわかる
  • 5.3 障害レベル管理表
    • 今あるものとそこまで変わらないシンプルさ。逆にこれぐらいシンプルじゃないといけないんだな
    • 影響度と緊急度(影響がどれくらい出てるか) それぞれで基準を定義し、最終的な障害レベルはマトリックスで両者掛け合わせて考える
  • 5.4 障害状況ボード
    • 障害発生時に使う。ストック情報で、同じ場所で最新の状況が更新され続ける

第7章 組織の障害対応レベル向上と体制作り

さまざまな観点から、自組織が3段階のどのレベルに位置してるのかを評価する、という話。

第12章 エンドユーザ向けの情報発信

  • 情報発信する内容
    • 掲載日時、影響範囲、原因、代替手段など
  • Point:障害発生中は原因について詳細にアナウンスする必要はない

    ユーザにとっては、システムの利用可否・自分がとるべき対応について知ることが大切だからです。

  • 12.2 情報発信の方法

    • Point:初報は詳細な内容よりもスピード重視。また定期的な情報発信を行う

あわせて読みたい

参考になりそうな他社事例とかの資料を貼っておく。

週末の SRE Kaigi 2025 でも障害対応関連での発表がいくつかあったみたい。

2024年のふりかえりと2025年にやりたいこと

例によって年が明けた後だけど昨年をふりかえる。

(ちょうど、はてなブログ今週のお題が「2024こんな年だった・2025こんな年にしたい」らしい)

去年(2023年)

2024年のインプット(読んだ本)

2024年に読んだ本はこちらです。

感想をアウトプットできてないものが多い。

ほか、途中まで読んだりしてた本はこのあたりか。

2024年のアウトプット(ブログ・登壇・etc.)

2024年に書いたブログは12記事でした。

はてなブログ

Zenn

ギリギリ月1ペース。もう少し書きたかった...
Zenn に投稿したのはいずれも会社の技術ブログでした。つまりプライベートではある程度まとまった知識のアウトプットをしてなかったことを意味する(はてなブログは雑アウトプット、Zenn はそれよりはもうちょっとちゃんとまとめた記事を書こうとしている)

2024年のGood & More

👍 Good

😫 More

  • ふりかえりが全然できなかった
  • なんとなく体調が良くない、という日が多かった
  • 仕事もプライベートも目の前のことに専念できてない、ぱっとしないなーと感じることが多かった
  • 大学全然通えなかった

雑感

2024年、一番の大きなチャレンジとしてはスクラムフェス大阪での登壇かなと思う。
それまではCREとしての活動は Customer系エンジニア座談会 というコミュニティで何回か登壇させていただいてて、徐々に知り合いも増えて慣れてきたところだった。
昨年はそのコンフォートゾーンから一歩踏み出して、プロポーザルを提出する・Customer 系エンジニアという属性じゃない方々の前で話すという、非常に良い経験ができた。

あと、AtCoder ちょくちょく継続できてる。本当はもうちょっとコンテストに参加したいなと思ってたけど、ふりかえると5月から10回ぐらいは参加できてたみたい。

反面だめだったところとしては、昨年は 今まで以上に定期的なふりかえりが実施できなかった。
仕事面で色々と置かれている状況が変わりばたばたしていたせいだと思うが、そのせいで1年のふりかえりを書くにも何をしていたか思い出せず、自己肯定感があがらん〜ってなってしまった。

習慣化と合わせて、ふりかえりを定期的に行うというのは2025年の課題である。

もう1つ、仕事もプライベートもいまひとつぱっとしなかったと書いたが、いろんなことに目移りしてしまってふりかえったときに「俺はこれをやった/学んだ!」と思えるものがあまりなかったのも反省点。

💪 2025年にやりたいこと

2025年も大きくやりたいことは変わらず。これは昨年のふりかえりに書いてたことだけど↓

今関心があるのはテクニカルライティングデータ分析とかSQL。あとコンピュータサイエンス系ももちろん引き続き興味はあって、今 OS について学んでるけど OS を理解するのに CPU の仕組みが知りたいなあとなっている。

この興味分野は今も変わってないかな。

昨年の反省として、そのときそのときで興味持ったものをつまみ食いしてたらあんまり達成感がなかった、というのがあったので、腰を据えて数ヶ月勉強するみたいなことができればいいなと思う。
Web 技術だと TCPTLS の仕組みをちゃんと学ぶ だったり、 ブラウザやデータベースを自作する とか。

あと、毎年なにか1個は新しいことにチャレンジしたいなと思ってやれてないことが多いんだけど、今年は 動画制作にチャレンジして VTuber になる というのを実現したい。
基本的には文章で書くのが好きなのでブログの方が性に合っているんだけど、動画編集ノウハウとか知っておくといろんなところで活かせそう。

UoPeople入学前に知っておくと良かった5つのこと

この記事は 社会人学生 Advent Calendar 2024 6日目の記事です。

こんにちは。@zaki___yama と申します。
私は普段 Web エンジニアとして働く傍ら、2021年頃から University of the People (UoPeople) というオンラインの大学に通っています。
今も細々と続けています。3年近く経ちますが休み休みやってるので、受講した科目は10もないぐらいです。

UoPeople に入学した動機はシンプルに、コンピュータサイエンスの基礎的な知識を学び直したいと思ったからです。
興味のある分野を独学で学ぶことも考えたのですが、カリキュラムという形で一定網羅的な内容が学べると期待したこと、また学んだ成果が学位という形で得られることも一定魅力に感じ、無理なら途中でやめればいいやと飛び込んでみることにしたのでした。

一方、事前にいくつかの大学を比較はしたものの、UoPeople には勢いで決めてしまった面もありました。
そのため、後々になって「えっ、そういう制度になってるの?」と知るようなことも多々ありました。

この記事では、主に UoPeople への入学を検討している方向けに、最初に知っておくと良かったなあと個人的に感じた点をいくつか共有します。
講義の内容には触れておらず、UoPeople という大学そのものの制度面の話です。

なお、私自身は今期単位を逃すと退学かもしれないというところまで追い込まれています。(2. 休学について を参照)

1. Tuition-Free = 完全無料、ではない

大学の Web サイト を見ると、いろんなところで「Tuition-free」を謳っています。
日本語に訳すと「授業料無料」でしょうか。

ただ、完全に無料で講義が受けられるわけではありません。
1個科目を受講するのにつき、受講後に assessment fee というのを支払う必要があります。

詳しくはこのページに記載があります。

学士の場合、1科目あたりの assessment fee は $140
(あれ、これまで支払ってるのは $120 だけどな...)
またトータルでかかるコストはだいたい $5,660 ぐらいだよと書かれています。

そしてもうひとつ注意点としては、単位を取得したかどうかによらず、最後まで受講した科目については assessment fee を払わなければなりません。支払わないと次の学期(term)の履修登録ができません(たしか)。
ですので、「私は学位取得は別に求めてないから、興味ある科目だけタダで履修しよ〜」というのは基本的にできません。

2. 休学について

参考:Inactivity - uopeople catalog

UoPeople では1年を5つの学期に分割しています。ある学期で1つも科目を受講しなかった場合、休学扱いになります。
また、連続して5学期以上休学した場合、退学 になります。

UoPeople allows students to be inactive for up to five (5) consecutive terms but not inactive for more than five (5) terms.

(more than だから5学期分まではOK、かな?)

明示的に休学することを選んだ場合に加え、普通に単位落としてその学期の単位が0、という場合も休学扱いになるので注意です。

3. 大学に在籍できる最長期間

参考:Academic Degree Requirements - uopeople catalog

Complete all requirements for the Bachelor’s Degree in no more than 50 terms of active enrollment excluding any periods of separation from the University.

50学期のうちにすべての単位を取得し終える必要があります。
ただし、「50 terms of active enrollment」とあるので、2で言及した休学期間は含まれません。

4. 科目のDropとWithdrawとFail

参考:Course Drops and Withdrawals - uopeople catalog

UoPeople では、学期が始まった後も科目の履修をキャンセルできる猶予期間が設けられています。
具体的には、

  • 学期開始〜最初の週までにキャンセル:Drop
  • 学期開始〜4週目までにキャンセル:Withdraw

というように呼び方が違います。

両者は、成績証明書にキャンセルしたことが記録されるかどうかの違いのようです。Drop は記載されませんが、Withdraw の場合は "W" と記録されます。
が、どちらも全体の成績には加味されません。

5週目以降になってしまうと、科目のキャンセルはできません。
加えて、そのまま単位を落としても assessment fee は支払う必要があるため、死ぬ気で単位を取る必要があります。

5. 履修する科目は自由に選択できない

これは私が在籍中に制度がいつの間にか変わった点です。Learning Pathway などと呼ばれています。

以前は科目ごとの Prerequisites(その科目を履修するために単位が必要な別の科目)を満たしてさえいれば、履修する科目は自由に選ぶことができました。

その仕様が途中から変更になり、現在は システムが指定した順番で科目を履修する必要があります。
ここには一般教養系の科目も散りばめられているため、「一旦興味のある CS 系科目を履修して、最後までいけたら学位取得を目指して一般教養などの科目も取りに行く」といった戦略がとれなくなりました。

正直、これで心折れそうになっています。

なお、CS の学士はこちらに Pathway が記載されています。
Bachelor of Science in Computer Science (BS-CS) - uopeople catalog

おまけ:UoPeople ぶっちゃけ続けられそうなのかという話

最後に、UoPeople に入学してみて今どう感じているのか、という率直な感想を。

正直に言うと払ってる金額に見合ってるのかなあとか、卒業まで続けられるか微妙だなあとは思っています。

その理由としては、1つは「5. 履修する科目は自由に選択できない」で言及したように自分で履修する科目を選べなくなったことが大きいです。
忙しい中でせめて興味ある CS 系の科目を受けたいのに、一般教養科目を強いられるというのは苦痛でしかない。

また、教材の質については他と比較してないのでなんとも言えませんが、課題についてはディスカッションや自身の考えを述べる系のものが中心で、教材の内容を問うものではないことが多いです。
個人的には、教材の内容をちゃんと理解しているか、といった観点で課題を出してくれたほうがうれしかったりします。

こちらの方が書いている内容は非常に共感できます。。。

おわりに

というわけで UoPeople の制度面の話を中心に、最初に知っておくと良さそうなことを紹介しました。
本格的に検討される際は、カタログに目を通すことをおすすめします。

最近だと、このカタログを PDF でダウンロードして ChatGPT に食わせれば、日本語であれこれ質問できるので便利です。

「論理が伝わる 世界標準の「書く技術」」を読んでパラグラフ・ライティングを学んだ

読みました。

読んだのは4月頃だったけどアウトプットをずっと放置してた。。。
いい本でした。

背景:ドキュメント書いてるときの個人的お悩み

社内のドキュメントやブログを書いているとき、たびたび

文章ってどこで区切ったらいいの?
なんとなく長くなったら改行入れたくなるけど…

みたいな気持ちになっていた。そのことを、テクニカルライター系の職種をやっている前職同僚に話したらこの本を勧めてもらった。

本書の目次

第1部  なぜ伝わらない、どうすればいい
  1  伝わらない文章がいっぱい
  2  なぜパラグラフなのか
  3  分かりやすさの基礎
第2部  パラグラフで書く
  1  総論のパラグラフで始める
  2  1つのトピックだけを述べる
  3  要約文で始める
  4  補足情報で補強する
  5  パラグラフを接続する
  6  パラグラフを揃えて表現する
  7  既知から未知の流れでつなぐ
第3部  ビジネス実践例
  1  通知文
  2  技術レポート
  3  社外文書

第2部まででパラグラフライティングの書き方については紹介が終わっており、ここまで約180ページ。
第3部はこれまでに学んだことを活かしての実践例(まだ読んでない)。

なので、第2部までならかなりさらっと読めると思う。

書籍の内容紹介

本書はタイトルの通り、パラグラフ・ライティングとは何か、なぜパラグラフで書くべきなのか、に加え、書くための具体的なテクニックについて紹介されている。

パラグラフとは何か

  • 1つのトピックを説明した文の集まりのこと
  • 原則として、1つの要約文と、複数の補足情報の文で構成する
  • さらに、各章は総論のパラグラフではじめる
  • ので、文章全体の構成としてはこんな感じになるはず

欧米では「アカデミック・ライティング」などの科目で大学1年生までにみっちり学ぶ、らしい。

「段落」との違い

  • 似ているが、パラグラフは「1トピック限定で、要約文がある」というところが違う
  • 段落は「①長い文章中の大きな切れ目。段。②転じて、物事のくぎり」(広辞苑(第6版 岩波書店))なので、そのような明確な決まりはない

パラグラフで書くと何がうれしいのか

  • ロジックの構成単位とレイアウトの固まりが一致するため、文章が論理的になり、読みやすくなる
  • 速読できる(読み飛ばしやすくなる)
    • なぜなら、冒頭の要約文を読んで理解できたら後半は読む必要がなくなるから

(p.78)
実は、飛ばし読みした方が、重要な情報が記憶に残ります

それな

面白いのは、この本自体が一貫してパラグラフ・ライティングのルールに則って書かれている点。

なので説得力あるし、読みやすい。

(一例として、本書のp.36-37)

そういえば「エンジニアのためのドキュメントライティング」にも「流し読みに適した書き方」という話があった。

(過去に書いたブログ「エンジニアのためのドキュメントライティング」を読んだ - dackdive's blog より)

パラグラフで書くためのルール

本書で紹介されているルールは7つ

  1. 総論のパラグラフで始める
  2. 1つのトピックだけを述べる
  3. 要約文で始める
  4. 補足情報で補強する
  5. パラグラフを接続する
  6. パラグラフを揃えて表現する
  7. 既知から未知の流れでつなぐ

1. 総論のパラグラフで始める

  • 総論のパラグラフがあると読み手はメンタルモデルを形成できる
  • 要約文「いま、業界にはA、B、Cの3つのトレンドがあります」
    • 読み手「なるほど、じゃあこの後は、A、B、Cの話が順番に来るのか」

4. 補足情報で補強する

  • 要約文の用語の説明や、要約文の根拠などを述べる
  • この補足情報まで読めば、読み手全員が要約文に納得するように説明する

5. パラグラフを接続する

  • パラグラフを「縦」と「横」に接続する
  • ロジックの構造と一致させる
  • 縦:ロジックが順番に展開されているとき。総論のスタートAからゴールDまでのキーワードを、各論の要約文でA→Dまでつなぐ
  • 横:ロジックが並列に展開されているとき

6. パラグラフを揃えて表現する

  • 5の横の接続において、文章表現を各論のパラグラフで一致させる

感想

  • パラグラフとは何か、は理解した。し、よさそう
  • 1パラグラフ1トピックにする、パラグラフ同士を接続するときにどういうことに気をつけたらいいか、はまだ具体的なテクニックに落とし込めていない

Q. 業務で活かせそうですか?

わからん

  • 自分は極力箇条書きにしてしまうきらいがある
  • 章ごとに要約パラグラフが必要になるほどの文章そうそうない

ということで、これをそのまま適用できるような文章を書く機会があるかというと…

ただ、パラグラフという考え方は理解したので、自分の文章をセルフレビューするときに
「最初の一行ずつ読んでも内容は伝わるかな?」
というレビュー観点が持てたのはよかった。

あと、結局文章にする前のロジックが大事だなという身も蓋もない感想もある。

気に入った一節

(参考:技術書は気に入った一節を見つけるだけでいい

(p.19)
●読み手に責任転嫁していないか
 伝わらないのは、読み手ではなく、書き手の責任です。
伝わらないことを、読み手の読解力のせいにするのではなく、なぜ伝わらないのかを反省すべきです。

「1.2 勘違いをしていないか」より。ズバッと言い切っていて良い。

また、続く文章には

伝わらなかったことは、文章の質が低いことを示すフィードバックなのです。このフィードバックが文章力を上達させるのです。

とある。

こっちが推敲して書いた文章を汲み取ってもらえないとどうしても読み手のせいにしたい感情が芽生えるけど、自分の書いた文章のどこが悪くてそう読ませてしまったのか?を考えて次に活かすようにしたい。(感情的には難しいけど!)

あわせて読みたい

このブログを書くために情報を整理してたときにこの記事を読んで知った。
良い文章の書き方とコツ、重要スキル:「パラグラフライティング」の解説 #初心者 - Qiita
同じ著者。気になる。

「Webブラウザセキュリティ」の社内輪読会をやった

読みたいなと思って2年近く積読状態だった本を、会社の同僚と一緒に輪読会形式で読んだ。
自分一人じゃ挫折してたと思うので誰かを巻き込んでよかった!

本書の目次

第1章 WebとWebセキュリティ
   1.1 Webを構成する基本の3つのコンポーネント
   1.2 プラットフォームとしてのWeb
   1.3 Webセキュリティ
   1.4 サーバーサイドWebシステムのセキュリティ
   1.5 クライアントサイドWebシステムのセキュリティ
   1.6 まとめ

第2章 Origin を境界とした基本的な機構
   2.1 Webリソース間の論理的な隔離にむけて
   2.2 OriginとSame-Origin Policy(SOP)
   2.3 CORS(Cross-Origin Resource Sharing)
   2.4 CORSを用いないSOPの緩和方法
   2.5 SOPの天敵、XSS(Cross-Site Scripting)
   2.6 CSP(Content Security Policy)
   2.7 Trusted Types
   2.8 まとめ

第3章 Webブラウザのプロセス分離によるセキュリティ
   3.1 Webブラウザが単一のプロセスで動作することの問題
   3.2 プロセスを分離した場合の問題
   3.3 Process-per-Browsing-Instanceモデルに対する攻撃
   3.4 Process-per-Site-Instanceモデルとその補助機能
   3.5 まとめ

第4章 Cookie に関連した機構
   4.1 Cookieの導入の動機
   4.2 属性によるCookieの保護
   4.3 Cookieの性質が引き起こす問題とCookieの今後
   4.4 まとめ

第5章 リソースの完全性と機密性に関連する機構
   5.1 問題と脅威の整理
   5.2 HTTPSとHSTS
   5.3 Mixed Contentと安全でないリクエストのアップグレード
   5.4 Webブラウザが受け取るデータの完全性とSRI
   5.5 Secure Context
   5.6 まとめ

第6章 攻撃手法の発展
   6.1 3種類の攻撃手法
   6.2 CSP下でのXSS
   6.3 Scriptless Attack
   6.4 サイドチャネル攻撃
   6.5 まとめ

第6章は発展的な話題ぽかったのでスキップ。

この本について

今回は輪読会の最後にそこそこ労力をかけて書籍の内容をまとめるという活動をやった。 せっかくなので冒頭の内容をそのままこちらに記載しようと思う。
(ほんとは全部書きたいけど書籍のネタバレになってしまうので控える)


本書の全体像

この書籍は、一貫して

WebブラウザはどのようにしてWebリソース間を適切に隔離(isolation)するか」

について書かれている。

具体的には、

  1. リソース間の論理的な隔離をどう達成するか
  2. リソース間のプロセスレベルの隔離をどう達成するか
  3. Cookieをどうセキュアに取り扱うか
  4. 出入りするリソースの信頼性をどう確保するか

の4つの問題に焦点をあて、第2章〜第5章まで各章ごとにそれぞれのトピックを掘り下げている。

本書の「序文」より引用

なぜ、このような観点を気にする必要があるのか?

1, 2:リソース間の論理的な|プロセスレベルの隔離

  • WebブラウザはさまざまなWebアプリケーションが同時に動作するプラットフォーム
  • 悪意のあるWebページを開いたことで、
    • 同時に開いている別タブの情報が読み出せたら?
    • Webブラウザに保存されているすべての情報(localStorageなど)にアクセスできたら?
    • →ユーザーが受ける被害は甚大
  • そのため、Webブラウザは、自身が取り扱うさまざまなリソース間を適切に隔離する必要がある
  • リソース間の隔離、と言ったときに、論理的な隔離プロセスレベルの隔離に分類して考えることができる
  • 論理的な隔離
    • たとえば「悪意のあるページを開いたときに、別のサービスへのHTTPリクエストが発行され、そのレスポンスの中身にアクセスできる」といったことがあってはならない
    • そのため、ブラウザは「そのリクエストを発行してよいか?」「レスポンスの中身にアクセスできるか?」という形で、論理的な制限を行う必要がある
  • プロセスレベルの隔離
    • たとえば、Webブラウザに任意のコードを実行できる脆弱性があり、悪意のあるページにアクセスしたときにメモリ空間上の任意の位置にある値を読み出せると仮定する
    • すると、攻撃者の罠ページから論理的には読み出せなくても、一度リソースに対してリクエストしてからメモリ空間を直接探索することで、Webリソースを読み出せてしまう
      • →といったことはあってはならない
    • このような問題は、Webブラウザのプロセスが適切に分離されていれば起こらない

3: Cookieのセキュアな取り扱い

  • リソース間の隔離だけではなく、リソースとWebブラウザ内のデータストレージとの隔離も考えなくてはいけない
  • Cookieは、Webブラウザ中に保存されており、かつHTTPリクエストを通して外部に送信されるという特徴がある。そのため、リソースの論理的な隔離、プロセスレベルの隔離に関する議論をそのままCookieにも適用するのは心もとない

4: 出入りするリソースの信頼性

  • ブラウザ内でリソースを隔離できていたとしても、リソースがブラウザに届く前に改ざんしたり盗聴したりできてしまっては意味がない
  • そのため、出入りするリソースの信頼性をどう確保するかにも関心がむけられるべき

各章ごとに学ぶキーワード

  • 2章(Webリソースの論理的な隔離)
    • OriginとSame-Origin Policy(SOP)
    • CORS
    • CSP(Content Security Policy)
    • (おまけ程度に)Trusted Types
  • 3章(Web ブラウザのプロセス分離によるセキュリティ)
    • ブラウザのIsolation Model
    • Site Isolation
    • CORB、CORP、COEP、COOP(ぐへえ)
  • 4章(Cookie
  • 5章 出入りするリソースの信頼性

感想

「本書の全体像」のところにも書いたけど、リソース間を適切に隔離するには?というテーマで一貫しており、かつ章ごとの内容は独立性が高いので気になるトピックだけかいつまんで読むこともできて良かった。

ただ、場所によっては説明が少々難しいと感じる部分があり、そのあたりはMDNなども適宜参照しながら知識を補っていった。

こちらの本も並行して読むとよかったかもしれない。

Same-Origin PolicyだったりCORS、CSRF、CSPのような略語表記の「なんか聞いたことあるけど人に説明できない」系の用語について、なぜそれが必要か?を理解しながら知識を整理できた。数ヶ月後に説明できるかは自信ないが、最後にちゃんとまとめたのでそれが活きると思いたい。

輪読会をやって良かったこと

まず何よりも、誰かと一緒にやることで最後までくじけずにやりきることができたので、同僚氏が誘いに乗っかってくれたのはほんとにありがたかった。わからないところも「うーんわからん!こういうことでは?」って言いながら前に進められたのは良かった。

あとは、CSPなどは特に業務ではあまり意識する機会がなかったせいか、みんな本当に使ってるの?とかイメージしきれない部分があったのだが、そういうときに実世界のユースケースをググってみたり実際のサービスでのリクエストをDevToolで覗いてなるほど〜とかやれたのはワイワイ感あって楽しかった。

CSPの事例でいうとこのあたり。