週末スペシャル： まじめに規制に従っている人ほど馬鹿を見る社会

no extension

3月は去りました。 春になっちゃったよ。

うっかり左手首を痛めてしまった（疲労がたまるとたまになる）のでいろいろ控えてた。 溜まりまくった小ネタを消化しないと。

  1. まじめに規制に従っている人ほど馬鹿を見る社会
  2. Linux サブシステムは Windows の終わりの始まり
  3. 鍵管理システム CONIKS
  4. Go 言語を使うようになって変わったこと
  5. その他の気になる記事

まじめに規制に従っている人ほど馬鹿を見る社会

もう何度も書いているが「警察にできることは犯罪者にもできる」。 問題は犯罪者にできることが警察にもできるかどうか駄菓子菓子…

FBI が端末を突破するのに外部企業を使ったということ，そして企業がそれに応じたことは重要だ。 もちろん実は NSA の息のかかった企業だった，としても驚かないけど。

企業は利があると思えば警察にも犯罪者にだって加担する。 今回の件のポイントは「犯罪者にできることが警察にできるとは限らない」と証明してしまったことだ。 セキュリティ企業は新しい時代の「死の商人」になるかもしれない。

警察が優位に立てるのは犯罪者よりもパワー（暴力・権力を含む）を有している場合のみである。 コンピュータ・ネットワーク技術あるいは暗号技術において政府・警察は優位に立てない。 米国司法省は法規制によって優位に立てると思ってるようだが，こんなもの最初から「法の外」にいる犯罪者やテロリストに対しては効力がない。

これは「飲酒運転を減らすために飲酒運転規制を厳罰化する」というのとは話が違う。 犯罪者にはインパクトがないし，まじめに規制に従っている人ほど「馬鹿を見る」ことになる。

有害なルールに従う必要はないし，それに従うことはむしろリスクを高めることになる。

Linux サブシステムは Windows の終わりの始まり

もともと Windows は POSIX サブシステムを持っている。 今回はそれに加えて Ubuntu ベースの Linux サブシステムを組み込むということらしいが子亀の上に親亀を乗っけるようなものだ。

Windows の基本的な設計思想は20～25年くらい前の古いものだ。 しかも DOS/Windows はもともとシングルユーザ用に設計されたもので UNIX 等のマルチユーザ向けの OS とは全く異なる。

Linux のベースとなっている UNIX もそうとう古いが，マルチユーザを前提とした考え方は今でも通用するし，なにより Linux はもはや UNIX に縛られない。

Windows は永遠に Windows に縛られ続ける。 Microsoft が満を持して出した Windows 10 も結局は Windows に縛られている。

Windows が時代遅れなのは明らかである。 Microsoft 自らこういう無茶をすること自体が「Windows の終わりの始まり」だ。 個人的に2020年までに自宅 PC のメインを Linux 機に換装する予定だが，ちょっと計画を前倒ししたほうがいいかもしれない。

追記

激しく同意。 もっとも私は ConEmu & NYAGOS だけど（笑）

WhatsApp がついに Signal ベースの E2E 暗号化を実装する

もともと WhatsApp が Signal ベースの暗号化システムを実装することは予告されていた。

Signal 自体は SMS アプリを置き換えることのできる優れたアプリなのだが SNS ベースのメッセンジャー・アプリとしては機能的に劣る。 WhatsApp がその辺を埋めることになるかどうか。 でも日本のユーザにはウケないかなぁ。

メールは ProtonMail， SMS ベースのメッセンジャーには Signal，それ以外のメッセンジャーには WhatsApp と，だいぶ揃ってきたねぇ。

鍵管理システム CONIKS

CONIKS is a key management system for end users capable of integration in end-to-end secure communication services. The main idea is that users should not have to worry about managing encryption keys when they want to communicate securely, but they also should not have to trust their secure communication service providers to act in their interest.
via CONIKS

とりあえずメーリング・リストに入ってみた。

Go 言語を使うようになって変わったこと

内容自体にさほど文句があるわけではないが（細かい部分は置いておいて），「interface を中心に設計する」という記述が気になって。

私はそんなにたくさんの言語を知っているわけではないが， Go 言語を勉強するようになって設計の考え方が少し変わった。 まさに「制約は構造を生む」（by 結城浩「数学ガール」シリーズより）が如く，言語仕様によって思考も影響を受けるのである。 以下にいくつか例を挙げよう。

Value Object から考える

さて，いつもの図。

Domain-Driven Design

Domain Layer の中身は Domain Service, Entity, そして Value Object に分類される。 ビジネスロジックは図の右側，つまり Entity や Value Object に記述されるのが良い設計だと言われている（記述の重複を避けられるため）。 ただし Value Object はしばしば省略されることが多い。

Value Object の特徴は以下のとおり。

  • 内部状態を持たず不変である
  • 属性（property）の比較のみでオブジェクト同士が等価かどうか決定できる

そして実装上の要件としては「軽量」であることが求められる。 何故なら Value Object は Entity の属性として使われることが多く Value Object がボトルネックになるとシステム全般へのインパクトが大きいからだ。

実は Go 言語はこの Value Object の実装にとても向いている。

Go 言語の特徴である「強い型付け」も Value Object を念頭に置いて考えるなら合理的な仕様であることが分かるだろう。

多態性を「振る舞い」から考える

Go 言語の多態性（polymorphism）は振る舞いによってのみ規定される（構造的部分型）。 つまり「猫」のように振る舞うのであれば実体がロボットだろうがコスプレイヤーだろうが全部「猫」として括れるのである。 そして「猫」のようにあるためにロボットやコスプレイヤーの identity を書き換える必要はない。 これはとても重要な事である。

たとえば「猫」を実装する際に，それに多態性を持たせなければならないかどうかは設計の割と早い段階で決めなければならないことが多い。 そうして先に interface などを決めなければ具体的なクラスを記述することができない。 しかし Go 言語ではアプローチが逆になる。 先にロボットやコスプレイヤーといった具体的な型（type）をバンバン作り，個々の振る舞いを見て，あとから「あっ，これ「猫」で括れるぢゃん♥」となるわけだ。 言い方を変えるなら refactoring 向きであるとも言える。

要件定義からコードを書く

これは Go 言語に限らないが， refactoring しやすい言語は prototyping に向いている言語であるとも言える。 Prototyping に向いているということはプロジェクトのかなり早い段階（たとえば要件定義）からコードを書けるということでもある。 結局エンジニアにとって信用できるのは百万語を連ねた設計書より「動くコード」なのである。

その他の気になる記事

参考図書

photo
プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)
Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田 芳樹 (翻訳)
丸善出版 2016-06-20
単行本（ソフトカバー）
4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN), 9784621300251 (ISBN)
評価     

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)