Robert C. Martin 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」

後知恵で極端な話になってしまっているのでは？というケースもあるが、これまでに筆者が関わってきたプロジェクトで発生した問題を背景として説明されており、割と現実味があるように感じられた。特に、システム開発プロジェクトで働いている人間が何を考えるか？を検討の遡上にちゃんと載せられているところがよい。

• p.30 いろいろ議論はあるけど「コード行あたりのコスト」って指標として受け入れやすいでしょ、という例。
• p.43 コード変更のコストがメリットを上回ると変更が「事実上できなくなる」。
• p.76 プログラミングのパラダイムはどれもコードの書き方に制限を加えている。新たな能力を追加しているわけではない。
  • 構造化プログラミングは、直接的な制御の移行に規律を課すものである。
  • オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである（依存関係の方向を制御できる）。
  • 関数型プログラミングは、代入に規律を課すものである。
• p.126 コンポーネント間の循環依存に注意という話。チーム間で他のチームのリリースを取り込むかという判断が発生するとか、コンポーネントのビルドの順番を決める必要があるという前提も現実に即している感がある。
• p.152 アーキテクトとして、方針と詳細を切り離すことで、できるだけ長い期間、できるだけ多く選択肢を残しておき、その間に適切に作るための情報を数多く手に入れるという話。文字通り受けとっていいかは別として、受けを広く取るのはその通りかも。あとは個別の事情（たとえば開発者のアサインとか）との兼ね合いですかね。例はどちらかちおうとp.158にあるものの方が分かりやすい（シングルスレッドで処理するとしても、マルチスレッド化してもいいように作っておくとか）。
• p.163 重複が本物の重複か偶然の重複か見分ける。偶然の重複を排除してしまったら（＝無理な一本化をしてしまったら）、あとから分離するのは大変。
• p.200 クリーンアーキテクチャって何？という話。
• p.286 「予算や納期が迫ってきたときに何が起こるか」を想定する（ルールを守らなくなる動機や正当化が生まれる）。
• p.297 Robert C. Martinが過去に関わってきた各種のプロジェクトの話。あまりにも完了しないプロジェクトが多いが、よくソフトウェア工学の学びはじめに言われる「完了しないプロジェクトが全体の何割」という話はこういうことなのか、という雰囲気が感じられる。

David Scott Bernstein 「レガシーコードからの脱却」

レガシーなコードベースから脱却する方法（ソフトウェアのモダナイズ）の本かと思いきやそうではなく、レガシーコードと呼ばれるようなコードを生み出してしまう開発者の振る舞いからの脱却について書いた本だった。2015年の本の翻訳。内容は分からんではないが、エピソードに基づく生々しさも、データに裏付けされた精緻な論理づけも、「全てが釘に見える」ようなやってみたさもあまり感じられないのはどうしてだろう。テストファーストなコードでステートメントカバレッジが100%になる話など、参考になる点も見受けられた。

• p.96 スクラムを使っている企業は全体の40%、うちCIをしているのは13%、うちCIの頻度が日次以上なのは37%。スクラムを使っていても日次以上の頻度で統合している会社は0.13x0.37なので5%未満。（State of Scrum Report 2013/6）スクラムを使って何をどうやるかが重要だし、なんならスクラムを使っている会社の大半は少なくとも当時あまりアジリティがなかったってことですかね。
• p.100 欠陥密度（コード1000行あたりのバグの数）は、チームや時間をまたいで比較できる数少ない指標。
• p.119 リモートワーク中のジュニアエンジニアは平行遊びをしない、ってこと？ あるいは、オフィス回帰はbabyがtoddlerになるだけの時間が経過したのがきっかけで何かに気づいたちめ？
• p.122 刑務所だと独房は懲罰房だけど、オフィスだと個室は特典ということになっている。でも花輪和一は雑居房より懲罰房が充実していたって言ってたよな。オフィスワーカーは花輪和一なのか？（でも花輪和一は「会社勤めができないから絵描きになった」って言ってたよな）
• p.147 アウトサイドインプログラミング。「コンシューマーの観点で機能を設計する」とあるが、それはトランザクションスクリプトと何が違うんだろう？
• p.167 最初にテストを書くと「失敗しているテストを成功させるのに関係ないコードは1行もない」状態になるから、コードカバレッジ（ここで言っているのはC0、statement coverageのことだろう）が常に100%になる。
• p.197 ユニットテストのコードカバレッジは100%を目指したいという話。テストを書かない言い訳を作らない。

いつも思うのだが「プログラムを継続的に統合する（Continuous Integration）ことでリスクを避けられる」と分かっていたのに、継続的に統合が可能な状態を作り上げてこなかったのはなぜか？ 継続的に統合が可能な状態があったのに、継続的な統合を避けていたのはなぜか？という理由があるはずなんだよね。つまり、単に「そんなこと知らなかった」以外にも統合しない機会・動機・正当化があるはずなのに、CIの仕組みだけ整えてヨシとしてるのは、それは不十分なんじゃないかな。それとも「そんなこと知らなかった」のまま開発者人生を終えてきたという人が大半だったりするのか？

崎村夏彦 「デジタルアイデンティティー 経営者が知らないサイバービジネスの核心」

• p.10 アカウンタビリティーとは、(1)自社サービスはどのような仕組みで提供しており、何かが起きたとき、それを正しく説明でき、(2)第三者による検証を可能にし、(3)もし説明が間違っていた場合には、「現状が把握できていなかった」として責任を取るという3点が実現されるようにすること。
• p.73 Identity Refereeという仕組みの話。Facebookの友達によるアカウント復活の役所版みたいなイメージと理解している。個人を最低2年間知っていて、身元確認済みであり、できれば公の職についていることが条件。
• p.74 考えてみれば、パスポートのICチップに入っている券面情報は暗証番号なしで読み出せるな。マイナンバーカードも、J-LISの署名つきの券面情報は券面に印字されている情報だけで読み出せるので真正性の確認はそれで行える。
• p.78 ニュージーランドでは運転免許証は属性確認用には使えない（副次的証拠でしかないため）。
• p.93 属性プロバイダーの例：Experian, LexisNexisなど。
• p.121 MAC(Mandatory Access Control)は管理者がリソースにメタデータを一括強制付与するもの、DACはリソースの作成者やシステムの利用者が制御できるもの。二者択一の概念ではなく、アクセス管理システムには両方の機能が必要。
• p.122 ABAC(Attributable Based Access Control)とRBAC(Role Based Access Control)、その前身のIBAC(IdentifierBased Access Control)の話。IBACだと管理がバラバラすぎてツラいのでRBACになり、RBACだと「国内にいる間はアクセス可能」みたいな動的に変わる属性を使えないのでABACになった。（この辺の話がCISSPのテキストだと薄かったんだよね）
• p.128 要求仕様は「OAuthを使うこと」だけではダメで、どのオプションを使うのか決めろとRFC6749に書いてある。どのオプションを使うのか決めろの例がFAPI。
• p.152 Bearer Tokenは「持参人トークン」の意味で、その心は「このトークンを持ってきた人には誰でも有効、たとえ泥棒が盗んできたトークンを使った場合であっても」。反対語は記名式トークン(Sender Constrained Token)で、発行を受けたものしか使えない。
• p.171 「アイデンティティとは何か」には自己像の自観と他観が関わってくる。では、ハンプティ・ダンプティの場合は？（自分が発した言葉は、きっかり自分の考えている意味を持つ……）
• p.188 提供する個人情報を属性ごとにチェックボックスで選択させるのはおかしいはずという話は面白いけど間がちょっと飛んでるように思われるので噛み砕く。画面上に出ているのが必要最低限の属性の許可なのであれば（そしてそうあるべき）、どれか一個でもチェックを外したらそれは「最低限必要な情報が揃ってない」ことになるので処理が続行できないはず。なので、属性ごとのチェックボックスたくさんでも、個人情報全体のチェックボックスひとつだけでも同じ用をなすはず。なのにわざわざ属性ごとにチェックボックスがあるということは「このうちどれかはオフにしても処理を続行できますよ＝余計な情報をゲットしようとしてますよ」と自ら言っていることに等しいですよ、ということ。
• p.196 同姓同名があるから氏名は識別子として不十分ですよ、というときの「同姓同名があるから」は「reassignable identifierである」と表現する。反対語は「non-reassignable identifier」。
• p.233 事業者のブランド評価と情報の非対称性（逆選抜）の話。
• p.237 何かの仕組みを「トラスト」するというのと、「その系が正しく動くことを知っている」とは別。その系が正しく動くことを知るためのコストを払えないからトラストに依拠しているわけなので。
• p.240 トラストフレームワークには(1)期待される成果を出すための技術とその実装、(2)それの適切な運用ルール設定とその遵守、(3)そうは言っても起きる失敗時の救済手段の整備、が必要。
• p.248 これは「自分の正義」なのだろうか？それともポリコレ棒に限らず、「そうしなければ、世界公正仮説に基づく自分の世界が崩れてしまうから（これまでこの祭りをすることでこの村を守ってきたのに、それを禁止されたらどうやってこの村を守ればいいのだろうという不安）」ということまで含めて「自分の正義」と言っている？
• p.249 データの正当な取り扱いにあたってのプライバシー告知の規格はISO/IEC 29184。
• p.252 mixiのときは「あしあとがないと誰が来たのか分からないから気持ち悪い」がマジョリティの意見だったよな。
• p.253 日常言語で書かれた規格書の解釈の揺らぎは不可避なので、それを準拠性テストスイート(FAPI Self-certification test)でカバーした話。規格書ですらこれだというなら、規格書でもないプロンプトならどうなることやら。

Tanya Reilly「スタッフエンジニアの道」

エンジニアがプロジェクトや組織に影響力を及ぼすことを生業にするとき、何を意識したり何に注意したりすべきかまとめたもの。いわゆるIC（Individual Contributor）むけの本だけど、PM（People Manager）だけど技術職のプレイヤーとしても評価されている、という人にはとても役に立ちそう。ただ、悲しいかな自分の知識や経験が不十分で「なるほどそうなのか」「たしかにそうだよね」「そういえばそんな話を聞いたことがあるな」以上の意見が持てない……何年か後に読み返したらまた学びがあるのかも。

• 第1章
  • レポートライン、スコープ、仕事の好み、現在の重点事項を解明し把握すること。ただし、組織を成功させるなら、軽油の樽を運ぶことでもあなたの仕事。
• 第2章
  • トポグラフィーマップの話が面白い。
  • 社内情報が公開主義だと情報の取捨選択に疲れてしまうし、公式の情報と初期構想を区別できないし、悪いアイデアをこっそり打ち切るのがより難しくなる。
  • 要塞の門番を迂回すると門番からの知恵は得られない。
  • システムのオーナーシップが複数チームに分散していてチーム間の紛争があるケースのプラットフォーム移行の話。
  • 正式な方法が最も簡単な方法でないとその方法は使われない。舗装された道を誰も知らなかったり、実際に行きたい場所に繋がってなかったりする。
• 第3章
  • いわゆる「叩かれ台」のことを英語では「ストローマンプロポーザル」という。
• 第4章
  • 自分の仕事について語るときに「常に火消しを行なっていた」になってしまう話。
• 第8章
  • 「吐き出すスペースが必要ですか、それともアドバイスをもとめていますか」という言い方は、相手によっては殴られるんじゃないかな。
  • 「口を開く前に頭の中で５つ数えるようにし、相手が考える時間を与え」るとあるけど、５つ数えられるのはそのあいだ何を言いたいのか覚えてられる人だけ。
  • 「彼らは学びたいのです」という前提に立ってるけど、単に「スタッフエンジニアに聞きました/見てもらいました」という免罪符に救われたい人の方が多くない？
  • プロセス文書のための前置きは興味深いが、機能するケースと機能しないケースとがありそう（特にプロジェクトのメンバーの能力やモラルの分散が大きい場合）。
  • 技術の採用基準とThoughtworks Technology Radar の話。

Fitbit Inspire 3は電源をオフにできない

問題

Fitbitの中には電源をオフにする操作が可能なものもあるが、Fitbitデバイスの電源をOFFにする方法を説明したページでは、Inspire 3は対象になっていない。

support.google.com

Inspire 3の操作方法説明にも、電源をオフにする方法は記載されていない。

support.google.com

実際にInspire 3の[設定]画面を開いても、再起動のメニューはあるが電源オフのメニューはない。

そのため、たとえば試験などで「電子機器の電源は切ること」のように指示された場合にどうするかは考えておく必要がある。

対策

設定電源をオフにできない機器に関する取扱が明示されていればそれに従う。たとえば普通の腕時計（Casio F-91Wとか）であれば試験によってはジップロックに入れて試験官にあずけたりできるんじゃないかな。

そうでない場合、そもそも「電子機器は電源がオフにできるもの」と思いこんでいる試験官もいるだろうから、音が出ないよう[設定]-[静音モード]を設定してカバンの中に入れておくくらいしか方法はないんじゃなかろうか……