2019-03-24

カメラ買ってから一か月経った

2/22にカメラを買ってからだいたい一か月が経ったので買った経緯とか、その後思ったことなどを羅列。

入門するにあたって様々な知人友人に相談した。彼らは皆IT技術者である。ITのことについて同レベルのことを聞くと「それくらい自分で考えろよ」と言いそうだが、カメラについては赤子に対するように懇切丁寧に教えてくれる
カメラが届く前に、勧められた入門書を買う。最初はほとんど意味がわからなかったが、後で実際に撮りながら見るとなるほどと納得することばかりだった。今後も逐次参照したい
もともと摂りたかったものは次の通り
- 落ち着きのない子供
- 動植物。小さいのから大きいのまで
- かっこいい風景(優先度はどちらかというと低い)
- 当時息子が興味を持ち始めていた星空(優先度はどちらかというと低い)
とりあえずSonyのα6400のダブルズームレンズキットとマクロレンズを購入
- キットレンズのうちの標準ズームのほうは小さいので持ち運びがとても楽。街を歩く時はこれがよいだろう。良くも悪くも撮れるのは肉眼で見られるものに近いので、同じくらいの小ささで、かつ、かっこいい風景が撮れるレンズがあるといいのかもしれない
- 私の望むものは広角レンズではなかろうかという声が挙がっているので近いうちに試してみる
- キットレンズのうちの望遠ズームのほうは荒ぶる息子を撮るのにとてもよい。近づくとカメラを破壊しようとしてきて危険なのでこれくらいは必要。あと動物園に行ったときには良い写真がたくさんとれた
  - 以前人に試させてもらった望遠レンズ(型番は忘れた)のほうが遥かにズームできたので羨ましいなあと思ったが、こっちのほうがだいぶ軽いので、さしあたり息子やら遠くの動物やらを撮る用途にはこれを使う
- マクロレンズはとにかく素晴らしい。日用品、および小さな動植物を撮るときにはこれがベスト。その一方でデカくて重いので、家族で出歩くときに使うには苦しい。一人の時間でその辺をうろつくとき用に使う。
- 星空用レンズについては、息子がしばらくすると星空に興味が無くなったらしいので買わなくてよかった
[instagram]https://www.instagram.com/satorutakeu/?hl=jaとかに上げる写真としてはwifi経由でスマホにDLした数百KB程度のjpegで十分
PCで高解像度版の写真を見ると「ここまで綺麗なのか」と驚いた
- ついでにいうとrawのサイズのデカさにもびっくりした。ここ数日一日数百枚撮っているのだが、それだけで数十GB食う。ストレージ容量が足りない
- 手持ちの非力なノートPCでは写真の編集はおろか画面に表示するだけでもけっこうもたつく。計算リソースが足りない
- 同、今は13インチのディスプレイで見ているが、大きな画面でも見てみたい
一枚に必要十分のことが表現されていれば最高で、過不足あればどんどんつまらなくなるというバランスが面白い。適当に撮ったものが良く見えたり、考え抜いて撮ったものがつまんなかったり
今後色々覚えることはあるだろうけど、まずは欲望のおもむくままに適当に撮りまくって理屈は後から考えるほうが幸せだし上達すると思うのでそうする。仕事じゃなくて趣味だし

2019-03-21

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

はじめに

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

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

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

コードレビューで「このコードはこういう理由で駄目です」と言われたらどう思うか。ここで理由は妥当なもの(仕様を守っていないなど)であり、かつ、口調や優しくも厳しくもないニュートラルなものとする。わたしは「感情に変化は無い」かな
— sat (@satoru_takeuchi) 2019年3月20日

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

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

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

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

何が起きたか

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

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

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

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

わたしの意見

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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

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

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

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

2019-03-21

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

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

2019-03-19

30分で論文流し読みシリーズ2: 「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の感想など。

実際の所要時間 30分
概要
- 課題: 組み込み機器のファームウェアから、ファームウェアに埋め込んだlinux(この論文ではfirmware embeddedable root file systemと表現される)を立ち上げる場合、ファームウェアのサイズはなるべく小さくしたいという要件をもとに、そのためにはユーザランドは帯に短し襷に長しの次のようなものにする必要があった
  - busyboxなどのCで書かれたプログラムを使う: 高速だが低級言語なのでセキュリティ攻撃を受けやすい
  - perlなどのスクリプト言語で書かれたプログラムを使う: 楽に書けるが遅い
- 解決方法
  - ユーザランドをGoで書く。ほとんどのユーティリティはバイナリではなくソースコードとして同梱して初回使用時にはコンパイルが走る
    - Goなので安全かつ楽に書ける
    - 最初は遅いがいったんコンパイルすれば高速。しかもGoなのでコンパイルは高速
感想
- 実行が高速で、かつ(Cより)安全かつコンパイルが高速なGoが出てきたからことできたこと
- バイナリではなく、それよりはるかにサイズが小さなソースコードを組み込むというアイデアは面白い
- ソース、とくにcmds以下がGoを覚えるための練習として役立ちそう

2019-03-18

30分で論文流し読みシリーズ1: 「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数は変化しない

2019-03-16

「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 valueのvalue最大サイズに収まる程度の小さいもの
- Adobeの事例がある
Nomad
- jobをsubmitするとnomad serverが空いてるところで適当に仕事を投げていく…のかな？
- jobを投げる側も投げられる側もシングルバイナリで実現。たとえばk8sのようなブートストラップがしんどいということがない
- k8sなどの大げさな仕組みが必要ない場合に使える。k8sなどとの比較はこちら
- jobはコンテナになっていることもあればそうでないこともある。詳しくはNomadのドキュメントを参照
- vault on k8sには消極的
HashiCorpは日本にはオフィスが無い。社員2人でリモートでやってる
参加者30人くらいのうちvaultを知っている人が10人くらい、実際に使っているのは一人。
HashiCorp製品に関する情報はgoogleで検索すればだいたい出てくる
製品開発はドキュメントファースト
勉強用の資料が充実している