コードは、業務のレア度や重要度には関心を示さないのだ

noteからの転載

つまり、何が言いたいかと言うと、タイトルの通り”コードは、業務のレア度や重要度には関心を示さないのだ”ということ。

人間が意味を見出さないといけない。

重要な業務のロジックだから品質保証をしっかりやろう！と言っても、実行するコンピュータはそんなことに関心を示さないし、そんな色付けをできるプログラミング言語を、私は知らない。そこに人間が意味を見出さないといけない。

当たり前のようで、これがなかなかコンセンサスが得られないことなのだ。

---

システムに実装されている業務と、人間が認識する業務の違いってレアリティの高い状態に対するスタンスじゃないかって思っていて、人間は「それは超レアだから、普段は気にしない、起きたら考える」って言えるけど、システムはそれを等しく（レアじゃないことと同じ粒度で）実装しなければいけなくて…

— magnoliak🍧 (@magnolia_k_) February 28, 2021

そうするとロジックだけを見ると「これはよく有るのか？無いのか？」みたいな判別ができないし、超レア（実は一つも無い）なパターンのために制約を外しておかないといけないとか、コードの見通しが分かりづらくなったりする

— magnoliak🍧 (@magnolia_k_) February 28, 2021

システムは制約を一律で考えるけど、人間はそこに暗黙のうちにレア度による優先度をつけている
ここがシステム側と、ビジネス側で会話が一番成立しづらいポイントじゃないかとか何とか

— magnoliak🍧 (@magnolia_k_) February 28, 2021

コードに色は無いけど、人間はそこにレア度による優先順位を見出していて、「そこはめったに通らないルート」「ここはめったに通らないけど、バグが有ると死ぬルート」「ここが通るかはDBの調査が必要」「これが発生したら100年に一度の事件」みたいな層別を行っている。

ただ、それは後世の人は容易に区別することはできないので、全部同じ粒度、同じ優先度で必要！と思ってしまうんだけど、案外「一回も使われていない」みたいなルートが多数を占めていたりする。

ビジネスの人は「細かいことはいいんだよ」と言い、システムの人は「その細かいこも含めて先に全部揃えておかないと後で死ぬ」と思っていて、その価値観の差異が会話を困難にしているのかもしれない。

『要求仕様の探検学―設計に先立つ品質の作り込み』……”要求されなかったことは決して実現されない”なんて話は30年前から言われていたことなんだ

要求仕様の探検学―設計に先立つ品質の作り込み

いつ買ったのかも覚えていないし、確実に買ったまま読んでいなかった本を本棚から発見して読み始めた。

『要求仕様の探検学―設計に先立つ品質の作り込み』……もうこのタイトルの時点でたぶんこの2021年において色々な人が読まなければいけない本じゃないだろうか。

本書は、長年システム開発のコンサルタントを勤めていたドナルド・C・ゴーズと、ジェラルド・M・ワインバーグによる所謂システム開発における”要件定義工程”のノウハウを解説した本だ。

原著は1989年に出版され、日本語訳が出たのも1993年と非常に古い本だ。タイトルだけ見るとウォーターフォール的な「最初の工程できっちり文書化することが大事」みたいなことが書かれている本と捉えてしまいがちだが、まったくそんなことはなく、現代でも通用することばかりが書かれている。というより、30年前から何も変わっていなくて、進化もしていないかもしれない。

もう冒頭から名言が連発。

• ”何について語っているのかさえわからないようなら、そのことについて正確さうんぬんをしても意味がない” - ジョン・フォン・ノイマン
• ”ソフトウェア・ビジネスは、製品開発に対する厳密な学という根拠のない幻想に悩まされていたのだ”
• "有効性は常に効率性よりも先にくる”
• ”するに値しないことは正しくするに値しない”
• "発見には価値がない；発見すること（探求（探検）すること）がすべてだ”
• "文書には価値がない；文書化することがすべてだ”

また、「I．コンセンサスの形成」には本書で最も大事なことが書かれている。

• あなたの望んでいることを伝えれば、ほぼ確実にそれが手に入る。
• あなたが望んでいることを伝えなければ、それはおそらく手に入らない。

当たり前のように思われるかもしれないが、ここでは一つの実験（4つのチームに、一つだけ要件を変えた仕様書を渡したときに何が実現されるか？）に基づき、説得力をもって解説されている。そう、本当に当たり前のことなのに、なぜこれが理解されないのか、解決するために努力されない事案がこんなにも多いのか。

---

その後続く設計の表記方法に関する論点も非常に興味深い。

もっと前に読んで色々な人に理解して欲しかったことが、全部ここに書かれていた。

そう、みんなオレオレ表記方法を「直感的でシンプルで理解し易い」と主張しすぎる。全然そんなことは無いのに……その表記方法が”表記しないこと”を理解することが一番大事なのに。そして実際の開発では常にその”画期的な表記方法”がサポートしないことをどうやって書き表していくか？ということを独自に工夫していった結果、「シンプルで直感的」とは程遠い成果物が出来上がっていってしまっているのに。

プログラミング言語や、設計方法論と同じで、「絶対に正しい解決策」なるものは存在しないし、そんなことを主張している人がいれば、まずは疑うところから始めるべきなのだ。

---

以降は、どうやってあいまいさを排除し、明確な要求・要件を特定していくか？という話がみっちり続く……が、個人的には以降は拾い読みでもいいかな、と思っている。割と会話調で続くとか、会議の良いやり方など、「この本でなくても……」とも言えるトピックも多いのだ。ただ、それがこの本に価値が無いか、というとそんなことはなく、冒頭の一貫したメッセージに基づいてプラクティスとしてまとめられているので、自分に必要と思える部分だけを拾えば良い。

それよりも、「あなたの望んでいることを伝える」ためにはこれだけの膨大な営みや注意点があるのだ、ということを理解することが大事なのです。

「なんかいい感じに提案してよ、プロなんだから」では絶対に良い成果は得られないんですよ。

---

ちなみに本書の最後に「読書案内」と称して関連書籍の紹介があるのだけど、その最初がクリストファー・アレグザンダーであり、まぁやっぱり良い思想・書籍は長い年月を経てもその価値は落ちないんだなって思った。

---

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

ワインバーグのシステム変革法 (ソフトウェア文化を創る)

ワインバーグのシステム洞察法 ソフトウェア文化を創る〈2〉

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

ワインバーグの文章読本

27inch 4K NEC LCD-EA271U-BKを半額で買った！…だけどMacユーザーは気をつける点が…

NEC 27型4K対応3辺狭額縁ワイド液晶ディスプレイ LCD-EA271U-BK

10年くらい前の印象だけど、NECのディスプレイというと業務用ハイエンド向けで、個人ではなかなか買えないっていうラインナップだった。

その後、9割が海外向けとなってますます個人では縁が無くなったし、今では社名も「シャープNECディスプレイソリューションズ」になってシャープ傘下になっていた。

そんなNECのPC向けのハイエンドディスプレイが、LCD-EA271U-BK。27inch、4K、Type-C接続対応……つまりEIZOでいえばEV2785に近いモデルだ。

jpn.nec.com

4月に新製品が出るらしく(メーカーのサイトに書かれている)、ずっと10万円以上の販売価格が2月に入って一気に半分に落ちて、5,5000円を切ってしまった。

価格.com - NEC MultiSync LCD-EA271U-BK [27インチ] 価格推移グラフ

ちょうど27inch 4Kディスプレイが欲しかったタイミングだったし、NECのディスプレイといえば以前から欲しかったので、買ってみた(このモデルはシャープの傘下に入る前に作られたもの）。

ただ一点を除けば、確かにアピールの通り色ムラも無いし、すみずみまではっきりした表示でものすごく満足度が高い。スタンドもガッシリしてて安定感が有る。さらに最初からメーカー5年保証付きだ。

その一点とは……現在出荷されている状態のファームウェアではmacにType-C接続で画面が映らないこと！！なんと！！

しばらくWindows PCでType-C接続していたので全然気がつかなかったけど、MacBook Pro 2017 Big Surで接続すると映らない！！マジか！！ 公式サイトには2018年時点で動作確認が取れていると書かれているので、その後のOSのアップデートで対応できなくなったみたい。 海外の掲示板でもEA271U(海外モデルの形式)がType-C経由だと映らないと書き込みが有った…解決策は書かれていなかった

で、焦らずシャープNECディスプレイソリューションズのサポートに問い合わせると、現在のファームウェアでは対応していないので修理扱いで引き取ってファームウェアのアップデートが必要とのこと。

箱も含めてシャープNECディスプレイソリューションズ側で用意して引き取りにきてくれるので特に費用はかからないけど、公式サイトに書いておいて欲しかった。

ただ、シャープNECディスプレイソリューションズのサポート窓口の対応はしっかりしていたので、その点は不満はなかったけどね。

ということで、5万円代で買えるならお買い得、ただし速やかにサポートに連絡してファームウェアのアップデートの手配をすること！という点だけが注意点のLCD-EA271U-BKでした。

たぶん、もうそんなに在庫が無いと思うので、買うならお早めに。

今はまだ引き取りの日程を待っているところなので、macにType-C接続したら、追加のレポートを書きます(HDMIでは何の問題もなく表示された)。

rust本

Rustの入門書のタイトル……

・実践Rustプログラミング入門
・実践Rust入門
・プログラミング言語Rust入門
・プログラミング言語Rust 公式ガイド
・プログラミングRust
・Rustプログラミング入門

— magnoliak🍧 (@magnolia_k_) 2021年2月26日

実践Rustプログラミング入門

実践Rust入門　[言語仕様から開発手法まで]

プログラミング言語Rust入門

プログラミング言語Rust 公式ガイド (アスキードワンゴ)

プログラミングRust

Rustプログラミング入門

『ビューティフル・コード』…美しいコードとは何だろう

ビューティフルコード (THEORY/IN/PRACTICE)

久しぶりに読み返している。

冒頭の竹内郁雄先生の推薦のことばはこのような書き出しで始まる。

最近，プログラムのコードの話をするのは，ソフトウェアのなんたるかをわかっていないような言われ様をするようだが，コードの話をしないで，なにがソフトウェアかというのが筆者の強い思いである。プログラムを書いたことことがないシステムエンジニアが威張っているような会社は早晩亡びる．プログラムコードには，およそ人が「書く」もののエッセンスのほとんどが詰まっている．よい問題理解に始まり，設計，製造，検査，保守改良に至るソフトウェアのライフサイクルをきちんと制御する能力の大半は，実は文章の力であり，文章の力はよいコードを書く力とほぼ等価である．つまり「美しいコード」を書けるということは，たとえ，コードを書くチャンスがなくても「美しいソフトウェア」を開発できるということなのだ．美しいソフトウェアを開発した人はそれを実際に体験・体得している．

なるほど……この文章が書かれたのは13年前だ(2008年に邦訳が出版されている)。果たして、昨今のソフトウェアを取り巻く環境は「美しく」なったのだろうか。

---

どういうコードが美しいかは諸説有るし、人それぞれの立場にも依るものだと思うけど、この本ではさまざまなコード例を挙げながら、「この観点で、美しい」が語られている。古い本なので、Perlをはじめとする動的型付が多く出てくるのは時代を写していて興味深い。いまならもっと「型！型！」と書かれているような気もする。

全部で33個のコードに関するエッセイ集であり、一つ一つ別の人が執筆している。なので、一つ一つの章は完全に独立していて、関連はないので、拾い読みにはちょうどよい一冊。ただ、教科書的な網羅はしていないので、その点は（本の厚さも含めて）期待しすぎるとちょっと肩透かしを食うかも。

なお、まつもとゆきひろさんが書かれたRubyの設計に関する章が一番読みやすかったし、理解しやすかった。日本語版向けにリライトされているそうなので、当たり前なんだろうけど。

ちなみに、「継承は美しくないから使わない」なんて話は出てきませんでした:)

---

原著はKindle版が入手できる。

Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)) (English Edition)

『入門監視』を読んで、僕らはどんな視点でシステムを"診る”べきなのか、考えてみた

入門 監視 ―モダンなモニタリングのためのデザインパターン

よく考えたら、この本を取り上げていなかった。今更だけど、出版から2年経った今でもまったく色褪せていない。

---

古代、システムの監視の世界はシンプルだった。

データセンタに専用の監視ルームが備え付けられ、24時間365日オペレータがアラートの発生を”目視で”監視していた(もう少し気の効いたシステムならパトランプが備え付けられ、そして鳴りすぎることで頻度が下げられ、「結局何のために設置したのか？」が忘れ去られる)。

エラーは主に死活監視で、インフラにしろ、アプリケーションにしろ、何かがエラーメッセージを吐けば、解析のための情報を手順書に則り収集し、保守メンバへ渡される。

そして、オペレータは、いつ起きるか分からないアラートを逃さないように、監視作業にまた戻っていく。

その繰り返しだ。

---

システム設計の中でも「監視」と、「移行」は難易度の高い分野の2大巨塔だ。

どちらも定番が無いし、さまざまな設計作業の最終局面においてようやく始められる。そして、設計をはじめる頃には動かせない要件が多すぎて、「目の前にある手段を工夫して、組み合わせて、やる」となりがちになる。

監視のターゲットが「監視を意識して」設計されていることはなかなか無い。

ミドルウェアのマニュアルにエラー監視の方法がきちんと書かれていることは稀で、とにかく「ERROR」とか「ABORT」といった「文字列の出現」を正規表現などを駆使して抽出する。監視が不足していれば追加するし、多すぎれば削除する。とにかく、絶対に最初から「ちょうどよく」ならない。

アプリケーションはなかなかきちんとしたログを出力しないまま異常終了を起こす。そして解析情報が不足していることで、原因の判明に時間がかかる。「間に合わせの」ログが仕込まれることは有るが、役目が終わっても取り除かれることなく蓄積していき、後世の人は目的の分からないログを撮り続ける……

---

『入門監視』は、そのような過去の監視の苦労を繰り返さないため、そして世の中の環境の変化（インフラ、アプリケーションの複雑化、インターネットサービスがよりビジネスへ直結、SaaS監視ソリューションの充実……)を取り入れるために、さまざまなプラクティスを紹介している。

『入門監視』というタイトルだけど、原題は「practical monitoring」……『実践モニタリング』といった方が適切で、この本を読んだからといってゼロから監視環境が設計できるわけではない。どちらかというと、一度でも監視設計をしたことが有る人がその考え方をアップデートさせるための本とも言える。

この本がなぜ重要なのか、読む価値が有るかといえば、得てして分離し易い「監視対象のアプリケーションを設計する人」「監視対象のインフラを設計する人」「実際に監視をする人」の三つの視点を一冊の中で一気通貫で語っているところ。

（監視ソリューションの入門書は、監視設定の方法は教えてくれても「なにを」監視すべきかまでは教えてくれない）

ビジネス視点、フロントエンド、アプリケーション、サーバ、ネットワーク……何を監視すべきか？を一気通貫で語っていて、どうすればシステム全体が一貫した価値観で監視できるようになるかをコンパクトにまとめている。

監視は、つまりリスク管理であり、システムの挙動の確からしさを可視化するものであり、そこには一貫した戦略が必ず必要になってくる。この本はそれを教えてくれる。自分の役割の、その向こう側を考えるきっかけになる。

監視を必要とする人、監視をする人の価値観を分断させてはいけないのです。

---

また、この本の特徴としてさまざまなアンチパターンがtipsとして載っていることが挙げられる。アンチパターンだけを読むのは時に危険なのだけど、背景が明確なので、何かのときに思い出すにはちょうど良い粒度だと思う。

---

あとはSaaS監視ソリューションの導入についてSongmuさんが書かれた付録Cは必読なので、これを読むためだけでも買う価値はあります。

---

あとそういえばサーバ監視といえば、最近こんな本も出たようです……今度読んでみようっと。

わかばちゃんと学ぶ サーバー監視

駆け出す前に『コーディングを支える技術』を読んでみるのはどうか

コーディングを支える技術――成り立ちから学ぶプログラミング作法 WEB+DB PRESS plus

よく初心者向けの定番書籍として『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』の名前が上がるけど、『コーディングを支える技術』もなるべく早い時期に読むことをお勧めする1冊だと思う。

この本の冒頭で、技術の学び方には、以下の3つがあると説明している。

• 比較から学ぶ
• 歴史から学ぶ
• 作ることで学ぶ

「作ることで学ぶ」系の本も非常に有効だけど、この本は筆者は「比較から学ぶ」「歴史から学ぶ」に多くページを割いていると書いている。

そう、いろいろな言語を複数比較しながら解説が進むところが良いのだ。現代では、ただ一つの言語だけですべて賄える、という訳にはいかず、さまざまな言語を使っていく必要がある。そしてそれぞれの言語の機能にはそれぞれ由来や思想がある。

プログラミング言語のさまざな機能を例示しながら、「なぜその機能が必要か」「この言語ではどうなっている、なぜそうなっているか」「どうしてそのような機能になってきたか」ということが丁寧に解説されている。

特に「第4章 処理の流れのコントロール」「第5章 関数」「第6章 エラー処理」はしっかり読むことをお勧めする。特に「関数」では「再帰呼び出し」が出てくるので、ここを理解できれば、もう勝ったも同然。

単に特定言語、特定ライブラリの機能を教えられた通りに使うだけより、背景を理解することで機能に対する理解度が格段に理解が上がり、結果として「何故こうなっているのか？」を考える習慣が身につき、「良いコード」が書けるはずだ。

ぜひ駆け出す前に、読んでみよう。

---

もちろん『リーダブルコード』もお勧めだけどね。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)