言葉をどう受け取るかは人それぞれ、かつ、多様ということを学んだ話

はじめに

最初に言っておきますが、とくにスカっと結論が出るような話ではないです。

昨日ふと「行為の否定」を「人格の否定」と捉える人がどれだけの割合でいるのか、人格の否定ととらえた場合はどういう感情が湧くのだろうか、ということに興味があってtwitterでアンケートを取ってみました。

わたしはソフトウェア開発に携わっていて、かつ、フォロワーも同業が多いだろうということで、コードレビュー*1を題材にしました。

「50-60人くらい答えてくれたら面白いな~」と思っていたのですが、最終的には3705人もの人から回答がありました。

設問文面については次のように考えて作りました。

  • いずれかの項目に誘導するような書き方にはしない
  • 「人格の否定」ではなく「行為(コーディング)の否定」であることを表すために「このコードは~駄目です」という書き方にした
  • 行為の否定は根拠があるものだということを表すために「このコードは"こういう理由で"駄目です」、および、「理由は妥当なもの」という書き方にした
  • 怒りや呆れなどのネガティブな感情を(少なくとも見た目上は)込めていないという意味で「口調は優しくも厳しくもないニュートラルなものとする」という書き方にした

単にデータだけを見ると「へぇ、なるほどね?」くらいで終わりです。ところが今回は、それ以外のところで考えさせられることがあったので本エントリを書きました。

何が起きたか

「自分はこう解釈した、こういう例があった」と返信ないし引用RTによって教えてくれたかたが非常に多かったです。わたしはtwitterのアンケート機能が好きでよく使うのですが、いつもは回答数の多寡によらず、こんなことはないです。

これら個々人の解釈が面白かったので列挙します。

  • 誤りを指摘してくれて感謝
  • フィードバックがあるだけでありがたい
  • 「やってしまった」と思って落ち込む、ないし自分に腹が立つ
  • 知見が増えるのでうれしい
  • 人格否定ではなくコードの否定であり、かつ、理由も納得できるので問題ない
  • 人格否定ではなくコードの否定なのはわかるが、「駄目です」という言い回しが嫌
  • 仕様を理解させてからコーディングさせてほしい
  • お金もらってるからしょうがない
  • 文面だと表現がキツく見えるので表現に気を付けてほしい # 例として絵文字をつける、などが挙がった
  • 対案を出してほしい
  • 何が妥当かによる
  • 「自分ならばこうする」「こうしたほうがいい」などと表現をやわらかくする
  • 誰に言われるかによる
  • レビューアのことを厄介者だと思う
  • レビューアのことを凄いと思う

これらの多様はもちろん、設問を私の意図と異なる解釈をされていることが多々あったのも驚きました。

わたしの意見

せっかくなので、わたしの考えについても単に「感情に変化は無い」だけではなく、ある程度詳しく書いてみます。

感情に変化が無い理由は「レビューアが否定しているものは人格ではなくコードだから」です。

言い回しについては次のようなことを思います。

  • 何かあればどんどん指摘してほしい。なぜならレビューの目的はコードをよいものにすることであって、それ以上でもそれ以下でもない
  • 本来言いたいことが伝わらないほどオブラートに包んだ言い回しは、意図を確認し直す手間がかかるだけなのでやめてほしい。例えば「わたしはこうしたいが…」が実質的に「こうしろ」を意味するなど
  • 言葉を荒げたりするのはレビューに何の寄与もしないし萎縮するのでやめてほしい

こういうことをされたら絶対に嫌だと思うことは次の通り。

  • 人格否定
  • 好みの問題なのに駄目と断言したり自分のやりかたにしろと命令してくる
  • 状況によって言ってること、および発言時の感情表現がバラバラ

その一方で、レビューをする側に立ったときには次のようなことを意識しています。

  • コードが仕様に従っていないなど、明らかに誤っている場合は「それはこれこれの理由によって間違っている」と言う
  • 好みの問題なら「そうした理由は何ですか。わたしはこれがいいとおもう」という。わたしの言うとおりにしてほしいのではなく「どっちがいいか一緒に決めましょう」という意味
  • 意図がわからなった場合は「これはどういう意味ですか」と聞く。責めているのではなく単なる確認

なるべく「否定しているのはあなたではなくコード」という意図がわかるようにソフトに言おうとはしますが、実際にできているかは不明です。

おわりに

今回の結果を受けて、わたしは次のようなことを思いました。

  • (表題の通り)言葉をどう受け取るかは人それぞれ、かつ、多様
  • どれも合ってるとか間違っているとかいうことはなくて、その人が事実そう感じるだけ
  • 全員が満足するレビューは難しい

最後のところを少し補足します。このようなときに「話し合って互いに幸せになれるやり方を見つけよう」という方法をとることもあります。しかしレビューをし合う人たちの「どうしても譲れない線」がぶつかり合っている場合の解決方法がわたしにはわかりません。たとえば次のような場合です。

  • Aさんは「直してください」という命令型の指摘そのものが受け入れがたい
  • Bさんは持って回った言い回しをするのが耐え難い

わたしとしては「どうしても譲れない線がぶつかった場合はどちらかが去るしかない、そのほうがお互い幸せなのでは」と思います。

なんかいい方法ないですかね。

*1:ソフトウェアのソースコードを書いた後で人に見てもらって誤りや改善点を探す工程

「カメラの教科書」を見た

今年から写真を趣味にしてみるかと思ってたときに人に勧められた本です。他の本を見たことがないので比較はできないのですが、いままでカメラを持ったことがなくて一切知識が無い今の私に必要十分なことが書いてあったと思います。カメラが届く前に見てもさっぱり意味が分からなかったのですが、使いながら改めて見てみると次第にわかるようになってきました。今後も実際にいろいろ撮影しつつ、わからないことがあったらこの本を見る、というような使い方でしばらくやっていこうと思います。

「U-root: A Go-based, firmware embeddable root file system with on-demand compilation」を読んだ

U-root: A Go-based, firmware embeddable root file system with on-demand compilationの感想など。

  • 概要

  • 感想

    • 実行が高速で、かつ(Cより)安全かつコンパイルが高速なGoが出てきたからことできたこと
    • バイナリではなく、それよりはるかにサイズが小さなソースコードを組み込むというアイデアは面白い
    • ソース、とくにcmds以下がGoを覚えるための練習として役立ちそう

「Schedule Processes, not VCPUs」を読んだ

最近思うところあって意識的に論文を読んでみようかなと思うようになりました。幸いにも研究者およびその卵である友人がいたので、いろいろ勧めてもらったものを読むことにしました。それらについてさらっと読んで要約して自分なりの感想をまとめてみようかなと思ってます。

初回はSchedule Processes, not VCPUs

  • 概要

    • 設定した問題: 仮想マシンにおいてははハイパーバイザによるvCPUのスケジューリングと仮想マシン上のプロセスのスケジューリングが二重にあることによっていろいろ問題があるのでそいつを解決しようぜ
    • 解決方法: どうやるのかというとゲストのvCPU数をハイパーバイザから見た負荷に応じて動的に変更させる。筆者はこの方法をvCPU-Balloningと呼んでいる。
    • 効果: 12コアのXeonマシンにおいて所定の処理の所要時間がXenにおいて1.5%から57.9%、KVMにおいて8.2%から63.8%高速になった。本記事では具体的にどういう処理を動かしたのかについては踏み込まない
  • 問題詳細

    • あるvCPU上でロック取ろうとした後に当該vCPUが乗ってるpCPU上でホストの処理ないし別vCPUの処理が動いた場合、以下のような様々な問題が発生する
      • vCPU Preemption
      • vCPU Stacking
      • CPU Fragmentation
      • priority inversion
  • 解決方法詳細

    • 以下によってpCPU上に複数vCPUを割り当てる事態の発生を最小限に抑えることによって設定した問題の発生を最小限に抑える
      1. 各ゲストにweightを与える
      2. 各ゲストにweight(全VMのweight合計)を整数値に丸めたターゲットvCPU数を設定する
      3. 各ゲストにターゲットvCPUを割り当ててそれぞれpinする。ターゲットvCPU数に増減がある場合はたとえばCPU hotplugによってvCPU数を増減させる
      4. ゲスト数が増減するときに2に戻る
  • 課題

    • ゲストのアプリがvCPU数の変動に対応しなくてはいけない
    • vCPU数を整数値に丸める必要があるので精度がそんなによくない
  • 感想

    • 論文のタイトルと実際論文で取り組んだことが一致してないように思う
    • これはそのそも解かなきゃならない問題なのか?
      • IaaSであればvCPUは通常占有させる
      • pCPUを複数vCPUで共有させる場合は性能をそれほど気にするほど頑張る必要はあるのか?
    • ゲスト上のアプリから見てvCPU数がコロコロ変わるのってけっこう辛くない?
    • 現在進行形で問題が起きていてもVMの生成/終了まで状況は改善しないのね
    • ロックの問題とスケーラビリティの問題がごちゃごちゃしてる
  • 自分ならどうする(既存研究があるとかないとかは知らない)?

    • weghtはとくに設定しない。vCPU数も変動させない
    • vCPUがアイドルになったらホストに通知する
      • そのvCPUが乗っているpCPU上にはvCPUは一つも乗っていないとみなす
      • vCPUがアイドルになるたびに上記のことをしているとオーバーヘッドが大きいのでアイドルになってから一定以上の時間が経つとvCPUを使っていない状態にするという閾値を設ける、などの凝った作りにしてもいい
    • この方法であればゲストから見たvCPU数は変化しない

「HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢」に参加してきました

はじめに

表題のイベントに参加してきましたので備忘録をば。

connpass.com

f:id:satoru_takeuchi:20190317165049j:plain
入場時にもらったノベルティグッズ。HashiCorp, Vagrant, そしてVaultのシール

HashiCorpの伊藤さんによる製品説明

HashiCorpの伊藤さんがHashiCorp製品について1時間くらい喋ってくれた。話した内容は覚えてる範囲では以下のこと

  • terraform enterpriseの諸機能
    • SaaS
    • Policy as code
    • 間違ったregionへのdeploy禁止
    • インスタンス作りすぎ防止
    • 国をまたいだ制約
    • SaaSでやってるサービスをプライベートで構築するPrivate Installということもできる
    • Terraform Enterpriseの秘密情報は実は裏でVaultを使って管理してる
    • terraformのコードを更新してmaster branchが変更されるとterraform enterpriseが動き出してplanが自動的に動く。設定によってはそのままapplyもする。
    • 30日間無料体験可
    • HA, DR機能。OSS版でもできなくはないが、enterprise版では面倒くさいところを全部面倒見てくれる
    • 鍵作成、暗号化、複合、電子署名、そのverification、鍵のローテンション、などなど全部できる
    • vaultによる暗号化はsecretでないもの、かつ、key valuevalue最大サイズに収まる程度の小さいもの
    • Adobeの事例がある
  • Nomad
    • jobをsubmitするとnomad serverが空いてるところで適当に仕事を投げていく…のかな?
    • jobを投げる側も投げられる側もシングルバイナリで実現。たとえばk8sのようなブートストラップがしんどいということがない
    • k8sなどの大げさな仕組みが必要ない場合に使える。k8sなどとの比較はこちら
    • jobはコンテナになっていることもあればそうでないこともある。詳しくはNomadのドキュメントを参照
    • vault on k8sには消極的
  • HashiCorpは日本にはオフィスが無い。社員2人でリモートでやってる
  • 参加者30人くらいのうちvaultを知っている人が10人くらい、実際に使っているのは一人。
  • HashiCorp製品に関する情報はgoogleで検索すればだいたい出てくる
  • 製品開発はドキュメントファースト
  • 勉強用の資料が充実している

learn.hashicorp.com

質疑

自分がした質問とその回答リスト。

  • Q: Vaultのdata encryption機能のusecaseは?
  • A: Vaultによる暗号化はsecretでないもの、かつ、key valuevalue最大サイズに収まる程度の小さいもの。

  • Q: Vaultのデータを保存するにはMySQLなどを選べるようだがVault EnterpriseのHA機能やDR機能の裏にはRDBクラスタ?

  • A: yes

  • Q: vault on k8sに消極的な理由は何か

  • A: k8sの証明書を誰が管理するか問題がある。などなど。社としては「Vaultは他のサービスの外に」と言いたい

  • Q: `vault write auth/approle/loginにおけるsercret_idなど、秘密情報が端末上で丸出しになることがある。回避策はあるか

  • A: ここを見るとよい

その他

f:id:satoru_takeuchi:20190317165108j:plain
HashiCorp箸

  • 質疑が活発で非常によかった
  • 伊藤さんはすべての質問を軽く打ち返してくれた。技術がわかる人なので非常によい
  • HashiCorpのブログがある

「肉食の思想」を読んだ

日本と西洋の違いを食文化、とくに肉食文化の違いから解き明かそうという本です。なかなか面白い視点なので思わず「なるほどね」と思ってしまいました。

ただし筆者も述べているようにデータの裏付けが少々足りないので、「これが事実に近い」というよりも、あくまで参考情報として認識するほうがよさそうです。この傾向は後半になるにしたがって強くなってゆき、どんどん筆者の想像が種となってきたのは残念でした。

Sonyのα6400を買った

はじめに

カメラが欲しかったのでSONYのα6400を買いました。

www.sony.jp

なのでどんなOSSを使っているのかをちょっとだけ眺めてみることにしました。

最初に断っておきますが筆者は組み込み機器のことを全然知らないので、「何言ってんだこいつ、なんでこんな基本的なことも知らないんだ」と思われたかたは訂正していただけると助かります。もう一点、この文書は細かいことにこだわらずにフィーリングで読んだことのメモ書きに過ぎないのでとくに自分以外の読者への読みやすさには配慮していませんし、内容の正しさの保証もしていません。

OSSSONY製品、およびα6400

SONY製品は他の家電製品の例にもれずにOSSをたくさん使っており、必要とあらば製品に組み込まれたOSSソースコードを公開しています。

下記ページから製品名からOSSソースコードをたどれます。

oss.sony.net

これは別に隠しページとかではなく、「sony open source」とかでぐぐればトップに出てきます。

α6400付属OSSのソースはここにあります。

oss.sony.net

α6400はどんなOSSを使っているのか

ソースコードの一覧は次の通りです。

compat-wireless.tar.gz
linux-kernel.tar.gz
qrencode.tar.gz
R8168-Driver.tar.gz
sony-target-dev-busybox-1.13.4-08020205.src.rpm
sony-target-dev-busybox-1.13.4-08020504.src.rpm
sony-target-dev-dosfstools-2.11-08020202.src.rpm
sony-target-dev-dosfstools-2.11-08020502.src.rpm
sony-target-dev-e2fsprogs-1.42-08020502.src.rpm
sony-target-dev-gcc-gplv3-libs-4.5.1-08020202.src.rpm
sony-target-dev-gcc-gplv3-libs-4.5.1-08020502.src.rpm
sony-target-dev-glibc-2.11.2-08020205.src.rpm
sony-target-dev-glibc-2.11.2-08020503.src.rpm
sony-target-dev-hostname-3.05-08020502.src.rpm
sony-target-dev-iptables-1.4.10-08020502.src.rpm
sony-target-dev-libnl-3.2.22-08020502.src.rpm
sony-target-dev-procps-3.2.7-08020202.src.rpm
sony-target-dev-procps-3.2.7-08020502.src.rpm
sony-target-dev-pump-0.8.16-08020502a.src.rpm
sony-target-dev-rpm-4.4.2.3-08020502.src.rpm
sony-target-dev-util-linux-ng-2.17.2-08020502.src.rpm

個々のソースについて細かく見るのではなく、どんなOSSのどのバージョンを使っているのかくらいだけを確認だけしました。興味の無いソフトについては飛ばしてます。

linux-kernel.tar.gzというのはその名の通りlinuxカーネル(以後"linux"と表記)ですね。最近は多くの家電製品にlinuxが採用されていますが、α6400も同様なようです。ちなみにlinuxのライセンスはGPL v2なので、SONYとしては製品を買った人にしかソースを公開する義務はないのですが、誰にでも見られるようにしてくれているようです。やったぜ。カーネルバージョンは3.0.27。3.0が2011年7月に出たもので、3.0.27は2012年4月に出たものです。うーん、7年ものか、古い。伝説に聞く「組み込み系機器に積んであるソフトは古い」というのが確かめられたぞ。そういえばセキュリティパッチはどこまで当たってるんですかね。diffがでかすぎるので追ってませんが、ちゃんと当てるべきものは当たっていることを望みます。なお、そうでない場合にどうなるかというとファインダー越しにDOOMが動くようになったりします。

compat-wirelessは新しいカーネルから古いカーネル用に無線LANのドライバをバックポートしたものです。とうの昔にバックポート対象が無線LANだけにとどまらず他のドライバにも及んで名前もbackportsに改められたはずが、昔の名前で出ています。古い。ちなみにこのパッケージを展開するとcompat-wireless-3.5.4-1-brcmという名前になりました。多分Broadcomの機器を積んでいるんでしょう。

qrencodeはQRコード生成ライブラリです。α6400にはスマホからQRコードを利用して本体と接続してデータをやりとりする機能があるので、それ用だと思います。

R8168-DriverというのはRealtek社のコントローラ(いわゆるカニチップ)を積んだNICのドライバでしょう…と、ここまで書いて思ったのですが、何で(少なくとも見かけ上は)Ethernetポートが存在しない機器にNICのドライバが必要なんだろう?

その他のソフトウェアについては理由はよくわかりませんがソースがsrpmとして提供されています。ソフトウェアによっては複数バージョンが存在することもありますが、番号が大きなほうだけを気にすればいいのかしら。0802...と続く部分は単に日付とも思えないし、一体何を意味するものなのだろうか。

busyboxlinuxの基本コマンドをシングルバイナリに詰め込んだものです。GNUツールの*-utilsなどのフルセットを持つよりもはるかに小さなサイズで最小限のことができるので組み込み機器などにおいて重宝されます。1.13.4というバージョンは2009年4月に出たものらしいです。うーん、これも古い。

dosfstoolsはFATなどのファイルシステムを操作するためのソフトウェアです。おそらくは本体に挿したSDカード上に存在するFATファイルシステムの操作をするために存在するのでしょう。

e2fsprogsはext系ファイルシステムを操作するためのソフトウェアです。おそらく本体に内蔵されているlinuxシステムのrootfsがext系ファイルシステムなのでしょう。

おわりに

噂には聞いていましたけどソフトウェアのバージョンがどれもこれも古いですね。私の慣れ親しんできたエンプラlinuxの世界でもカーネルバージョンが古い古いとよく言われますが、組み込み機器においてはさらに古いようです。別にけなしているわけではなくて、単に「ほんとにそうだったんだ」とびっくりしているだけです。いい経験になりました。

では、α6400で写真撮ってきます。