2020年買って・使って良かったもの
Starbucks VIA Instant Coffee
普段はコーヒーよりお茶を飲んでるんだけど、リモートワークが続いて飽きてきたのでコーヒーを飲み始めた。コーヒーは香りと味が強いので飲むとメリハリが付く。とは言っても豆を挽くほどこだわる気もないので、インスタントで色々探している。アメリカではK-Cupという機械で抽出するためのポーションが主流で、インスタントコーヒーやドリップパックがあまり売られていないので探すのも難しい。
近所のスーパーに置いてあったStarbucks VIA Instant Coffeeというやつが中でもおいしかった。10包入りで8ドルくらい。中でもItalian Roastというフレーバーが香りが良く、酸味もあまり強くないので好き。
フィリスのアトリエ
3月から自宅勤務＋外出自粛になった影響で急激に暇になったので、mikutter界隈で流行っているアトリエシリーズをやってみようかと思ってライザのアトリエをプレイした。そしたら思っていた以上に面白かったので、専門家の助言の下で一つ前のシリーズである不思議シリーズもやることにした。
不思議シリーズの錬金術はポリオミノの敷詰めで、素材ごとに色や形の違うポリオミノを正方形のフィールド内に配置して、色の個数や特定のマスを埋められたかによって出来上がるアイテムの効果が変化する。適当にやっても素材が良ければそれなりのアイテムができるけど、強い効果を発現させたければ投入順や配置を考える必要があって、一気にパズルっぽくなる。そうして作った高性能なアイテムを使って冒険をするので、まさにロールプレイングという感じでワクワクする。
錬金術で必要なアイテムを作るというシステムもさることながら、不思議シリーズは世界観とキャラの魅力もかなり高い。特にフィリスのアトリエは、広大なオープンワールドのマップを探検するというシステムになっていて、本当に冒険しているみたいでとても楽しい。ファストトラベルも充実しているし、フィールドの解放感が高いので、移動もあまり苦にならない。
2作目のフィリスのアトリエだけを遊んでも十分に面白いとは思うけど、前作の主人公のソフィーが話に絡んでくるので、先にソフィーのアトリエから遊んだほうがより楽しめると思う。あと公式サイトは異常なレベルのネタバレをかましてくるので、ストーリーを楽しみたいならプレイ前には見ない方がいいと思う……。
使い捨てゴム手袋
去年から使い続けているけど、使い捨てゴム手袋は引き続き便利だった。
これは使っているやつそのものではないけど同じようなやつ。
生肉を料理したり、生ごみを処理したり、排水溝の掃除をしたり、そういう直接触りたくないものや触ると汚れが付いて面倒なものなどを扱うときに気軽に使って捨てられるのが良い。特に今年はコロナの影響で料理をする機会が増えたので、活躍の場も増えた。なんか値上がりしてるけど……。
ハーゲンダッツ 蜜いも
9月半ばに日本に帰ってきたとき、Twitterでバズっていたので試しに買ってみた。
まあイモなのでおいしいんだけど、これはその中でも焼き芋の香ばしさと甘さが強く感じられるので完成度が高い。定期的に買って冷凍庫に常備していた。
Jabra Evolve 75 Headset
リモートワーク用に買った。ヘッドセットなので持ち歩きできるし、音質も結構良い。ただし耳当て部分が少しきつく、長時間つけていると耳が痛くなってくるので、ゲーム実況をするときなどは他のヘッドホンを使っている。
Riedel VINUM Cognac Glasses
コニャック用のちょっといいグラス。去年買って使い続けている。
コニャックに限らず、度数が高く香り高いタイプの酒を飲むのにちょうどいい。ウイスキーもこれで飲んでる。香りを広げるグラスの構造もさることながら、飲み口の部分が薄いので普通のコップ等よりも酒が味わいやすい。特別な処置なしで食洗器で洗えるのも高ポイント。
2020年の目標 - 11月まとめ
月が変わったからまとめ書かなきゃ……と思っていたらライザ2が発売されたのでそれどころではなくなってしまった。省エネモードで書きます。
ゲーム。トトリのアトリエの2周目をやってラスボスを倒した。あと冒険者ランクを最高にした。流石にライザ2の前に終わらせとかないとやる気失うなと思ったので……。12月までにはメルルと新ロロナの延長戦も終わらせる予定だったけど楽観視しすぎできすね。
ソフィーのような地図システムとロロナの錬金システムが合わさっているのは面白いんだけど、2周目をやると錬金素材を特性でフィルタできなかったり効果が素材選択画面で確認できなかったりと、ちょっと大味なところが目に付くようになってしまうので周回モチベが維持しづらい。ストーリーもあんまりないしね。ラスボス倒した後も各地に強敵が現れるのでやり込みもできるんだけど、制限時間付きという根底のシステムと相性が悪い気がする。錬金のUIがせめて新ロロナくらいまで洗練されていてほしい。
あとボドゲ会をした。MtGのゼンディカーの夜明けドラフトと、マーダーミステリーの王府百年というシナリオ（なんか有名なやつらしい）。マーダーミステリーは初めてだったけど、人狼とRPGを混ぜたような独特の雰囲気が面白かった。しかし全てのプレイヤーが秘密を持っていると言えないことが多すぎて、犯人が有利すぎるような気がする。実際今回は真犯人にほとんど近づけなかったし、他のシナリオ経験者に聞いても多かれ少なかれそんなもんらしい。
株。なんもやってない。
体重。旅行ついでに計ったら11/22の時点で70kgくらいだった。ちょっと増えすぎてんよ～。車移動の旅行だったので一時的に増えてただけだと思いたい。
新しい技術。osak.jpをHugoで書き直して、コードレビュー記事の英訳版を公開した。
アクセス解析も埋め込もうと思ったけど忘れてたな。12月の課題とします。そういえばコードレビュー記事の補遺を書くみたいな話もしてたけど何もやってないな。これも12月の課題とします。
中国語。今月も何もやっていない。
本。Twitterの広告でやたらと流れてくるので嘘喰いを読んだ。運否天賦のギャンブルに見せかけて、裏では仕込みや心理誘導をすることで勝ちを必然にしていくという、カイジの地下チンチロや沼を彷彿とさせる勝負をひたすら繰り返す感じの漫画。頭脳戦でありながらギャンブルのヒリつきも感じられるので1粒で2度おいしい。バキみたいな対人格闘要素も結構ある（個人的には格闘部分はあまり好きではなかった）。ストーリーもしっかりしていて面白い。
あと、集合と位相を真面目に勉強し始めた。教科書はこれ。
数学もゲーム性があるので時間がいくらあっても足りない気持ちになるが、頭が限界を迎えるのも早いので1日3時間くらいしかプレイできない。生活の他の部分を捨てれば6時間くらいはできると思うが、家では集中できないのがネック（数学を進めるときは基本的に近所のコメダに行っている）。これを書いている12/4の時点で4章（距離空間）の終わりらへんまで進んでいる。
旅行。10月末からの四国～近畿旅行に加え、突発の草津温泉1泊2日と熊本～鹿児島3泊4日旅行をした。草津温泉はいかにも観光地という感じではあるが、その分ホスピタリティがしっかりしているし、温泉もバラエティに富んでいて良かった。睡眠が崩壊している時期に行ったので昼間にあまり行動できなかったのが心残り。そもそも温泉街にいろいろ食べ歩きや飲食店があって面白そうなので、2泊3日くらいでじっくり遊びたい。
熊本～鹿児島は@brsyweの案内で温泉巡りをした。どこも良かったが、指宿温泉の砂蒸し風呂が特に良かった。温泉で暖められた砂に埋まるという風変わりな風呂（っていうのか？）だけど、砂の重みを感じながら全身がまんべんなく暖められる気持ちよさは普通の温泉では体感できない。鹿児島は焼酎もうまかった。機会があればまた行きたい。
指宿の次点では杖立温泉が良かった。泉屋旅館というところに泊まったのだが、そこで出されたほうじ茶プリンがとてもおいしかった。温泉も広くて良かった。
11月下旬から各地でコロナ感染者数が増え始めて危なげなことになっているが、アメリカみたいに崩壊しないことを祈るばかり。年が明けたらそのアメリカに帰るんだけど……。
2020年の目標 - 10月まとめ
日本生活2ヶ月目。日本に慣れてきた。
10月30日から四国・中国地方へ旅行に出た。この文章を書いている時点（11月5日）が最終日なので、10月にやったことなのか11月にやったことなのか微妙。とりあえずそのうち旅行記録を書きます。
旅行の記念に制県レベルをやってみた。
意外と行ったことすらない県が多い。秋田は中学生の時に修学旅行で行ったかもしれん（よく覚えてない）。群馬は一度くらい行っときたいですね。
ゲーム。ロロナのアトリエのイベントをだいたい開放したのでトトリに移った。マップやシナリオの作りはソフィー、自由度の高さや各地を旅して開拓するというゲームシステムの雰囲気はフィリスに似ている。調合システムはロロナと基本同じだけど、特性でフィルタできなかったり、調合に使うアイテムの情報が見づらかったりとちょっと不親切に感じる。ロロナは新ロロナとしてリメイクされているからちょっと改善されてるのかな。ソフィーと同じ広いワールドマップ＋狭い探索マップの組み合わせは好き。日数制限があるとソフィーと違って遠くに行くときにちょっと緊張感がある。リディスーはワールドマップはおまけ程度＋探索マップがめちゃくちゃ広いという逆の組み合わせで移動が面倒に感じることが多かった。縮尺の小さいマップで大きく移動させるのが世界を広く見せるコツなのかな。
1周目では船を作って東の大陸に行き、ギゼラの足跡を探し当てたところでタイムアップ。ノーマルエンドだった。Mastodonで報告したら初見ノーマルエンドなのを驚かれた。とりあえず強い武器を作って2周目に持ち越したけど、錬金システムの面倒さが思いのほか負担になっていて2周目を始めてすぐのところで半月以上放置している。流石にtrue endくらいは自力で見ておきたいが……。
株。あんまり判断材料がないので動いてない。
体重。温泉に行ったついでに計ったら67kgくらいだった。70kgくらいまで到達してるかと思っていたのでひとまず安心ではある。
新しい技術。ようやくコードレビューの記事を上梓した。ちまちまと書き溜めてたんだけど、完璧になるまで待ってたら無限に公開できないなと思って切りのいいところでエイヤで公開した。
そしたら1000ブクマ以上ついて、はてブのデイリー1位になったりウィークリー1位になったりした。今は英訳を準備してるんだけど、読み直すと言葉が足りず論旨がよくわからなくなってる箇所や議論の飛躍がちょこちょこあって恥ずかしい。こんなクオリティでも1000人以上が役に立つと思ってくれるのはちょっと意外で、理想的な出来になるまで待つよりもどんどん出力していった方が総合的に見てプラスになるのかなあなどと思った。書かないと文章うまくならないしね……。興味深いコメントもTwitterやブコメで見たので、11月中にはそういった内容も含めた補遺を書きたい。
また、英訳版のコードレビュー記事を公開する場所を作るため、osak.jpをHugoで書き直している。書き直しって言っても元々自己紹介1枚しかなかったけど。英語圏で技術記事を公開する場所は日本のはてなやQiitaのようにこれというキラーサービスがあるわけではないっぽいが、肌感覚ではMediumが多め、自分のサイトでHugoやJekyllで公開してるのが次点、その他サービスはたまに見る程度という感じだったので、せっかくだしosak.jpで配信することにした。
新しく覚えた技術はないけど、アウトプットができたのは良い。ちょっと肩の荷が下りた感じ。
中国語。今月も何もやっていない。
本。なんか知らんがTwitterでプロモーションがめちゃくちゃ流れてくるので、バキを3部まで読んだ。プロモーションはなんかのマンガアプリだったけど、それとは無関係にebookjapanで全部買った。根強い人気があるだけあって、戦いの描写が濃くて面白い。格闘技の皮を被ってるけどこれ超能力じゃない？みたいな技を真面目に格闘技っぽく描いているという点でテニプリと同じようなノリを感じる。
鬼滅の刃も読んだ。1巻を読んだ段階では妙に淡々とストーリーを進めるだけでそんなに面白くないな？と思ったけど、2巻以降からキャラも話も動き出してどんどん面白くなっていった。ここ10年～20年くらいで面白かったマンガのエッセンスを煮詰めて再構成した感じで、昔の他のマンガで見たモチーフが結構出てくる。一番面白くなるようにストーリーを動かすためには後出し説明も上等という吹っ切れた作り方なのに、ギャグや勢いで押し切っているのがすごい。
10月はコードレビュー記事と仕事でほとんどの時間が消費されていた。相変わらず深夜に働いて昼に起きる生活をしているが、いつ働くのをやめればいいのか分からなくなりがちなので時間をちゃんと管理できるようにしたい。11月はThanksgiving等でアメリカ人の生産性が落ちてくる頃なので、仕事じゃない活動にリソースを割けるようになる……といいな。日本にいるうちにもっとGoToしたい。
コードレビューの目的と考え方
まえがき
コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコをもらうためだけの無価値なプロセスになってしまう。
かくいう自分も、はっきりとコードレビューの目的を意識したことはなかった。単純に、人間は間違えるものだし、様々な要因によってより良い解法を見落としてしまうものだから、そういった間違いや改善を指摘するためにコードレビューがある、という程度の漠然とした理解だった。コードに関わる人数が少ないうちはそれでもいいかもしれないが、コミッターが増えてくるにつれ、レビューで指摘した方がいいのか微妙なケースや、レビュワー間での意見の食い違い、更にはレビュワーの意見を頑として受け入れないコミッターが出てくるなど、目的が明文化されていないことによる弊害が目に付くようになってきた。
本稿では、コードレビューの目的が何であるかを再考するとともに、その目的を達成するための鍵となる考え方をまとめる。これらは自分の経験に基づくものもあるが、インターネット上に公開されている文書から拝借したものも含まれる。本稿を書くに際して、特に参考にしたWebサイト等の一覧は末尾に載せている。その他にサーベイ段階で発見した文書のまとめは Scrapboxで公開している。
本稿に加えて他に参考文献を読む場合、まずはCode Review Best Practices[3]を読むことをお勧めする。この記事はコードレビューの進め方について、本稿では省略した部分も含めて大変よくまとまっている。さらに時間があるのであればeng-practices | How to do a code review[1]とeng-practices | The CL author’s guide to getting through code review[2]を読むとよい。
コードレビューの目的
大目的
- 実装者の他に少なくとも一人、マージされたコードをメンテナンスできる人が存在するようにする。
- 実装内容について合意を形成する。合意内容は要求仕様と実装が一致していることの他に、既存のコードとの一貫性やメンテナンスのしやすさ、スタイルに関するものなど全て含まれる。
コードレビューの主要な目的は、書いたコードの内容を他のチームメンバーに理解してもらうことである[1][3][7]。「3か月前の自分は他人」という言葉に代表されるように、コードを書いた本人ですら時間が経った後には詳細を忘れてしまっており、もう一度コードを読み直すしかないというケースは非常に多い。今すぐに他人が読んで理解できないコードは、もちろん将来も理解されていないし、何なら書いた本人も3か月後には理解できなくなってしまう。そうなったコードは拡張することも難しいし、直接そのコードを触らなくても他の箇所の変更が間接的に影響を及ぼすかもしれないため、システムの安定性に対して大きな負債を抱えることになる。
問題を引き起こしている箇所のコードが読めないときはシステムが壊れても諦める、という選択を取るのでない限り、最低でも他に1人、理想的には全てのチームメンバーが変更内容を理解しているべきである。逆にレビュワーは、いずれ自分がそのコードを保守、修正、拡張しないといけないという意識でコメントをつけるべきである。したがって、レビューコメントはミスや改善可能な点の指摘だけではなく、コードの意図に関する質問も含まれる。
よく言われるようなバグの指摘は目的としては含めない（指摘するなと言っているわけではなく、バグを発見するためにレビューするのではないという意味）。理由は以下の2点である。
- バグの指摘はレビューコメント全体の15%を占めるにすぎず[5]、レビューで見落とされるバグも多いという指摘がある[4][5]。
- 自動テストの網羅性を上げたほうが中長期的にはメリットが大きい。
小目的
どのように大目的を達成するかはプロジェクトやチーム規模、企業風土など様々な要因によって変わりうる。ここでは、大多数の環境で大目的の一部（あるいは、大目的の具体的な言い換え）になると考えられるものを挙げる。
- コードがシステム全体の信頼性を（大きくは）下げないこと
- Googleのeng-practices[1]では"Don’t accept CLs that degrade the code health of the system"と言い切っているが、場合によっては多少の信頼性低下もトレードオフとして受け入れてよいと思う。その境界はチームとプロジェクトに強く依存する。
- テストカバレッジやコードの複雑性が信頼性の指標となる。
チェックリスト
コードレビューに際し、見落としがないようにチェックリストを活用するとよい[8]。チェック項目を考える際には以下の点に注意する。
- 高優先度の指摘を一通り洗い出すまで、より低い優先度のレビューについては考えないようにする[1]。
- 優先度の低い指摘はそれと分かるようにする。コメントの文頭に[nit]を付けるなど（nitはnitpickingの略で、ささいな粗探しという程度の意味）[1][3]。
- 優先度の低い指摘が対応されていなくても、機能の重要度や時間的制約を加味して考え、場合によってはGoサインを出す。
- 優先度の低いものは、大抵後からでも修正できる。後からの修正が難しいような問題は優先度が高いものとして考える。
優先度高（大きな損失を生む問題・後からの修正が困難な問題）
- 要求仕様と実際の機能が一致しているかどうかの確認
- 外部サービスの特殊な挙動やセキュリティ機構など、コードやテストのfailureとして直接現れない、環境との不一致や問題になりやすい点の指摘
- 将来的に修正しづらくなると（経験的に）分かっているデザインや実装方針の指摘
- 巨大なクラスや関数を作っている、よりよいデザインパターンが知られているなど
優先度中
- 複雑性の評価
- シンプルな実装やライブラリで置き換えられないか？
- 理解の難しいコードは適切にコメントされているか？
- 既存ロジックとの一貫性
- 将来的な拡張性の評価（そもそも拡張されうるか、新規実装より拡張のほうが好まれるかも含む）
- コーナーケース等バグの発見
- テストが書いてあるかの確認
優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題）
- コーディングスタイルの確認
- 外部ドキュメントの更新
レビューを負担にしないために
レビューサイズのコントロール
大きい変更をレビューするのは負担が大きい。規模が大きくなればなるほど相互作用するコードも増えてくるし、見落としもその分多くなる。また、大量のコメントがついたコードレビューは単純に見づらい。Code authorの視点からも、レビューに時間がかかってマージが遅れるのは望ましくない。
レビュワーは、コードレビューが大きすぎると感じた場合は細かく分割することをcode authorに求めてよい[1]。レビューに20分以上かかるラインがひとつの目安となる[3]。レビューが大きくなりすぎる理由としては以下のような理由が考えられる。
- 互いに無関係な変更が1つのレビューにまとめられてしまっている。
- リファクタリングと機能変更が一緒くたになっている。
- 既存のコードまたは実装方針が悪く、巨大な変更が余儀なくされている。
このうち最初のものは、機能同士が無関係であることを説明できれば分割してもらうのは容易い。2つ目は、リファクタリングと機能変更を分けてレビューに回すことで解消できる。普通はリファクタリングで触る個所と機能変更で触る箇所は重なっているため、code authorも両者の分離を意識してコードを書く必要がある。一般論として「機能は変更しない大規模なリファクタリング」と「機能を変える小規模な変更」を別々にコミット、レビュー、デプロイすると認知負荷を軽減しやすい。
最後のものに関しては、おそらくコードレビューよりも外側での対処が必要となる。既存のコードがあまりにも複雑で、そのままでは変更が巨大になることをどうしても避けられないのであれば、リファクタリングに一定の工数を割くことを検討した方がよい。実装方針が悪い場合は、code authorのスキル不足が考えられるため、レビューに留まらず1 on 1やペアプログラミング等を活用した教育も視野に入れる必要がある。場合によっては無理を通してマージしてしまっても良いが、レビューが不完全になるぶん、挙動に対してはっきりとコンセンサスの取れていないコードがマージされてしまうリスクを意識する必要がある。
誰がレビューをするか
コードを理解している人を可能な限り増やす、という点ではコードに関わる人全員がレビューすることが望ましく思えるが、全員がレビューに割く時間を捻出することは現実的ではないし、非効率でもある。さらに議論に関わる人間が増えると意見がまとまりにくくなる。このような理由から、レビュワーの人数は1～2人程度が望ましいと思われる[3]。この場合、1人はTech Lead等プロジェクト全体を俯瞰する役割の人、もう1人は変更されている箇所に特に詳しいと思われる人（git blameしたときにたくさん名前が出てくるなど）にする。
人数を限る理由は、先述の通り非効率性と議論のまとまりやすさによるものが大きい。したがって、これらの問題を別の手段で解決できているなら多すぎることを特別問題視する必要はない。例えば、レビュワーとしてコードを読むこと自体が人のコードを読む練習として機能するし、そのプロジェクトやプログラミング自体に不慣れな人にとっては望ましいパターンを覚える絶好の機会でもある。議論が紛糾しそうになった時にどうやって落としどころを見つけるかが事前に共有されていれば、多人数でレビューすることは特別危険ではない。
議論をどうまとめるか
コードは書いたようにしか動かない。コードを批判するにせよ、批判から防衛するにせよ、そこには明確なロジックとメリット・デメリットの説明があるはずである。そういった説明をできないのであれば、基本的には相手の言っていることを受け入れるのが正しい。
議論に参加している各々が少しずつ異なる軸で実装を評価し、こっちがいい、いやあっちがいいと議論が紛糾することはよくある。実際にレビューされている実装と、それに対して提案された修正がどっちも甲乙つけがたいのであれば、Code authorの意見を尊重する[1]。既に実装が書かれている分、手戻りが少なく楽だからである。適切なコードレビューの手順を踏めば、その実装に対する問題点は既に共有されているはずであるから、将来その問題が表面化したときの問題解決は、レビューがされなかった場合よりも格段に楽なはずである。
批判と個人攻撃
「コードレビューでの批判はコードに向けられたものであり、個人に向けられたものではない」というメッセージは様々なところで強調されている[1][2][3][6]。コードレビューを個人攻撃だと捉えてしまう人に対し、そうではなくてこれは論理的な議論のプロセスなんだよ、だから傷つく必要はないんだよと諭し、心理的安全性を向上させるためのメッセージだとされている。このメッセージは欺瞞とまでは言わないが、多分に建前を含んだ言い方だとは思う。
コードレビューの際、code authorが誰であるかは大きな情報を含んでいる。過去に同じ箇所を何度も変更したことがある人のコードは信頼できるだろう。逆に、初めてその箇所を変更する人や、他のレビューで問題の多い変更を出してきた人に対しては注意深くなるだろうし、そうするべきだろう。同じような理由により、レビューコメントに何を書くかもcode authorによって変わりうる。以前の会話やコミット内容などから一定以上の習熟度があると分かっている人に対しては簡潔なコメントを書くだろうし、習熟度の足りていなさそうな人には時間をかけてでも詳細なコメントを書くだろう。こういった事情から、レビューコメントはcode authorに対して多かれ少なかれ、また意識的にせよ無意識的にせよカスタマイズされることになる。これは単にcode authorも人間なのだからウェットな配慮も必要であるというだけの話ではなく、その人が必要としている情報を過不足なく提供することが議論の進め方としてもっとも効率が良い、という実用上の理由も大きい。人のアレコレに触れなければpolitically correctだし心理的安全性も害さないからみんなハッピー、というような単純な話ではない。
このようなレビュワーの事情に加えて、code author側にもコメントを個人的に受け取る理由がある。プログラマーにとって自分の書いたコードというものは、少なからず自分のアイデンティティへと結びついているものである。例えば仕事で書いたコードであれば、それは給与に直結する。そもそもプログラムの良し悪しは、思考の質の良し悪しが色濃く反映される。レビューを書いた側も個人に向けた要素があり、受ける側もコードと個人を結び付けて考えるのであれば、レビューコメントに対して個人的な感情が入ってしまうことはなんら不思議ではない（この辺の話は以前のエントリでもまとめている[9]）。
以上の議論を踏まえると、より適切なメッセージは「コードレビューでの批判は、少なくともコードに疑問の余地があるからなされている」だと思う。そもそもコメントを攻撃と受け取るかどうかは、受け手の思考パターンによるものが大きい。場合によっては心に大きく刺さるかもしれないが、何もレビュワーもcode authorをめちゃくちゃに破滅させてやろうと思ってコメントしているのではなく、追加の対話なしでは受け入れがたいコードがただそこにあるからコメントしているのである。もちろんレビュワーの方も、読み手がどう思うかを多少なりとも考えて、あまり度が過ぎないように注意してコメントするべきであるし、code authorの習慣や能力に対する悪口は言うべきではない（どうしても言いたい場合は組織ならマネージャーに言う。インターネットなら単に相手を無視する）。この辺の機微は普通の人間関係、普通の会話と変わらない。
レビュワー向けアドバイス
- 細かいコーディングスタイルより、設計を第一にレビューする[1]
- 設計レビューのほうがより広範な知識を必要とする。すなわち、あなたと同じレビューコメントを付けられる人のいる可能性が低くなるため、相対的にコメントの価値が高い。
- 間違った設計は、その後に書かれるコードにも影響を与える。
- コーディングスタイルはlinterやauto formatterで自動的に修正できるのが理想
- よっぽど変なスタイルでない限り、後からリファクタリングできる
- 「自分がこのコードをメンテナンスする」という観点でレビューする
- コードレビューの大目的のひとつは、複数人でコードに関する知識を共有することで、誰か一人が単一障害点となることを防ぐことにある。その共有先はあなたである。
- 自分が理解でき、正しく保守や拡張ができると言えるコードであるかどうかを最優先に考える。
- 自分の考え方を押し付け過ぎない
- Code authorの書いたコードと自分のイメージが食い違っていた場合でも、書かれたコードのほうが劣る点を明確に指摘できないのであれば、Code authorの方針を尊重する[1]。
- もちろん「自分ならこう書く」といったアドバイスを否定するものではない。
- 人ではなくコードを批判する
- 可能な限りコードを書いた個人への言及を避ける。「このコードを書くようなやり方は悪い」ではなく「このコードはこういう問題があるため好まれない」、「この設計は考え方がおかしい」ではなく「この設計はこういう場合に破綻するため修正が必要である」のようにする。
- 人によってはコードと自我がかなり密接にくっついている場合があるので、言葉遣いは注意するに越したことはない。
- 人への言及を避ける方法は言語や文化によって様々である。一般論としては、人ではなく物を主語にした論文のような文体を意識すると、個人への言及と取られるような文を避けやすい。
- 可能な限りコードを書いた個人への言及を避ける。「このコードを書くようなやり方は悪い」ではなく「このコードはこういう問題があるため好まれない」、「この設計は考え方がおかしい」ではなく「この設計はこういう場合に破綻するため修正が必要である」のようにする。
- 良い設計やスタイルを見つけたら褒める
- 悪いパターンと同様に、積極的に意識するべき良いパターンというものも存在する。そういうパターンを見つけたらちゃんと褒める。
- Code authorはたまたま良いパターンを書いただけで、その真の価値に気づいていないかもしれない。実験的に新しいパターンを試してみただけで、保守性を上げるかどうかは深く検討していないかもしれない。あなたがそのパターンが良いと知っているのであれば、その知見を共有することで学習効率を上げることができる。ポジティブなコメントは、単にそれだけで「認められている」という意識を与え、モチベーションの向上につながる[4]。
- Code authorからの質問には必ず答える[1][3]
- レビュワーがコードの内容や背景を理解できないことがあるのと同様、Code authorも知識量の差や単なる説明不足によって、レビューコメントを理解できないことがある。Code authorはそのギャップを埋めるために質問をしているのだから、レビュワーは必ず答える義務がある。
- Code authorからの質問の結果、当初のコメントが間違っていたと分かることもある。その場合、「こういう時は正しい」等の正当化を並べる前に、大筋では自分のコメントが間違っていたことを認めてはっきりと述べる。
Code author向けアドバイス
- レビューはなるべく小さくする[2][3]
- レビュワーへの負荷を軽減するため、コードレビューの大きさは小さい方がよい。可能な限り小さい変更で目的を達成できるようにする。
- 新しいコードはなるべくprivateな関数に閉じ込める
- 新しいフィールドより新しいローカル変数、新しいローカル変数より新しい関数を作るようにする。影響範囲の小さいコードは多少の瑕疵があっても、以下の理由によりOKを出しやすい。
- 既存の振る舞いが壊れないことが分かりやすい
- 後でリファクタリングがしやすい
- コンテキストをMerge Requestやcommit message、チケット等で可能な限り説明する[2]
- レビュワーも詳細なコンテキストや要求仕様を知らないことは多々ある。
- レビュワーは「なぜ」この変更を「しなくてはならないのか」が知りたい。この質問に端的に一文で答えられるとよい。答えられない場合、問題の理解が甘いか、チケットの粒度が大きすぎる。
- レビュワーの質問は攻撃ではない
- レビュワーはそのコードを自分がメンテしないといけないという前提でレビューする
- レビュワーから質問が出るのは、プレゼンすると質問が出るのと同じ。チケットとコードだけでは共有できない思想はめちゃくちゃ多い。
- レビュワーの質問には必ず答える[1][3]。答えられない場合、レビュワーの質問がおかしいか、もしくはレビュワーがあなたの知らない知識を（この領域に関して）知っているということである。どちらにせよ「分からない」ということを明らかにして、逆にレビュワーの意図を聞き出す。 -「分からない」ということを明示しないと、よほど文章構成がうまくない限り、レビュワーはあなたが「レビュワーにとって未知の知識を元にして、信頼できる返事を書いている」と解釈する。そうなると認識に齟齬が生まれ、無用ないさかいの元になる。
- コードへのコメントはあなたへの攻撃を意図してはいない
- 自分の書いたコードには愛着が多少なりともあるだろうから、批判的なコメントに傷つくことはあるかもしれない。ただ、レビュワーはあなたを傷つけるためにコメントしているのではない。単に、そのコードが問題を起こす可能性が高いと思うからコメントをしている。
- 世の中は広いので、本当に攻撃を意図してコメントする人もたまにはいる。そういうケースはもはやコードレビュー以前にコミュニケーションの問題なので、通常の社会的制裁の手段に則って対処する（上司に報告する、無視するなど）。
- 批判的なコメントを受けることが多い場合、あなたの能力が低いと糾弾されているように感じるかもしれない。
- 「能力が低い」はある意味で正しい。問題を起こしにくいコードを最初から書ける人に比べると、大量のレビューコメントを受け取るような人の生産性は相対的に低くなる。このことについて精神的な負担を感じるかは、個人のキャリア観と期待値設定の問題である。レビューコメントが精神的な負担になっているのであれば、マネージャー等に相談すること。
- 自分の書いたコードには愛着が多少なりともあるだろうから、批判的なコメントに傷つくことはあるかもしれない。ただ、レビュワーはあなたを傷つけるためにコメントしているのではない。単に、そのコードが問題を起こす可能性が高いと思うからコメントをしている。
参考文献
- [1] eng-practices | How to do a code review
- [2] eng-practices | The CL author’s guide to getting through code review
- [3] Code Review Best Practices
- [4] Lessons From Google: How Code Reviews Build Company Culture
- [5] Code Reviews Do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down - Microsoft Research
- [6] コードレビューを成功させるためにCTOが考えるべき7つのこと
- [7] Why code reviews matter (and actually save time!)
- [8] Code review guidelines - CodeProject
- [9] クソコード批判とクソコード批判批判はなぜ燃えるのか
2020年の目標 - 9月まとめ
日本に移住しました。
色々と悩みはしたものの、アメリカにいるよりかは安全だし自由だろうと思って、年明けまで日本にいることにした。オースティン―ダラス便は満員だった一方でダラス―羽田便はほとんど人が乗っておらず、鎖国の厳しさを感じた。8月末に空港での検査がPCR検査から抗原検査に切り替わっていたこともあり、1時間待った程度で入国はかなりスムーズだった。あと久しぶりにAmerican Airlinesに乗ったけど、相変わらず機内食がおいしくない……。
検疫にもゆるキャラがいるのがいかにも日本らしい。
仕事は日中と深夜に3～4時間ずつ、日本時間とアメリカ時間に合わせて働いている。流石にチームメンバーの大半がアメリカにいる以上は重要なミーティング等はアメリカ時間でスケジュールされるし、リアルタイムで話すチャネルを完全に失うのもまずいので……。元から生活リズムは適当なのでこの労働体系自体はそんなに苦でもないが、働いた時間を管理しづらいのが欠点だと思う。
ゲーム。アメリカを発つ前にリディー＆スールのアトリエを周回しなおしてトゥルーエンドを見た。総プレイ時間は全部で100時間くらい？先月の記事には98時間と書いてあったけど多分間違いで、あの時点では90時間くらいだったと思う。リディスーはクリアしてからが本番っぽいのでパルミラとテルミナの周回とか強敵巡りとかもやりたかったが、グラボも積んでないThinkpadでプレイするのは無理だろうと思って泣く泣く諦めた。
で、日本ではSwitchでアーランド3部作をプレイしている。とりあえずロロナのアトリエから初めて、1週間で1周クリアした。そのあと延長戦に突入したらトトリとメルルが出てきて、これはリメイク前等でのアーランドプレイ済みを想定しているのか？と思っていたら識者（@toshi_a）に同意を得たので、とりあえずエンディングだけ集めようと思って周回を始めた。2周目は王国課題を適当にやっていたら点数が低すぎてトゥルーエンドフラグが立たなかった上、交友値上げも思ったより時間がかかったので、これはどうしようもないと思って攻略サイトを解禁した。今は3周目をやっている。クーデリアかわいい。
不思議シリーズ以降に慣れていると、ロロナの調合システムは自分で決められるパラメータが少なく、最初は物足りなく感じた。ただ周回を前提とするゲームならこの軽さで正しいような気もする。王国課題の評価システムは、一目見てリディスーじゃんと思った。いや逆なんだけど。リディスーの評価システムはストーリー上で存在している必然性が薄かったけど、ロロナのようなストーリーを前提としたものなら納得がいく。
本当はロロナのエンディング回収もサクッと終わらせてトトリを始めようと思っていたんだけど、ゲームをやる時間があまり取れていないこともあり、思ったより時間がかかってしまっている。ライザ2までにアーランド終わらせようと思っていたけど無理な気がする。
株。あんまり気にしてないが、コロナショックの落ちてる途中で買った株が復活し始め、ついに含み益を生むようになってきた。あと毎月証券口座に送っている余剰資産がまとまった額になったので、いくつかの銘柄を買い足した。短期の値動きは何が何だか分からんので、長期でどうなるか予想を立てて買うという戦略で相変わらずやっている。
体重。新居に体重計がないので定期的な計量ができてない。9月半ばに温泉に行ったときに量ったら67kgになっていた……。アメリカでも日本でも同じように引きこもってるのになんで増えるんだ。自己隔離期間を終えて買い物や食事で出歩くようになったので、ちょっとはマシになると思いたい。
新しい技術。先月まとめたコードレビューのサーベイを元にコードレビューのガイドラインを書いている。アメリカを出る直前に書いていて、日本で続きをやる予定だったけど、あんまりやる気が出なくて1ヶ月放置していた。最近またやる気が復活してきているので、今週中にはブログ記事として出したいところ。
他は特に何もやってないな……。会社のインフラがEnvoy + gRPCに移行しつつあり、Mastodonでも@shibafu528がgRPCを触っていて面白そうなので、周辺技術を触りたいと思ってはいる。あとmikutterプラグイン開発とかもしたいね。
中国語。今月も何もやっていない。
本。飛行機の中でうらら迷路帖を読んだ。芳文社祭りの時に以下の記事でおすすめされてたやつ。
レビューでも触れられている通り、ストーリー要素の強いファンタジー作品で面白かった。こういう作品が読みたくてきららを読んでいる。
同じく飛行機の中で「SF映画で学ぶインタフェースデザイン アイデアと想像力を鍛え上げるための141のレッスン」を読んだ。SF映画に出てくるコクピットの計器や空間ディスプレイ、果てはR2D2のようなロボットやマトリックスの脳直結に至るまで、様々なインターフェースについてそれらの視覚的、実用的な意味を論じている。翻訳の文体にちょっとクセがあるものの、流し読みするだけでも十分に面白いし示唆に富んでいる。紹介されている映画も名前は知っていながら見ていないものが多く、一通り見てみたくなった。Kindleで購入したが、流し読みのしやすさや辞書的に使うという意味で、紙で買った方がいい本だと思う。
Database Internalsはちょっと進んで11章まで読んだ。というかこの辺になるとDesigning Data-Intensive Applicationsとの重複が多く、説明もそっちの方が分かりやすいので、これ以上読まなくていいんじゃないかという気がしてきている。あとは流し読みでいいかなぁ。
会社が在宅ワーク支援として$500だけ（非合法なものでなければ）なんでも経費で落とすよというキャンペーンをしてくれたので、ちょっと前にTwitterで見て気になっていた二酸化炭素計を買った（このへんの話）。単純に二酸化炭素濃度が健康へ及ぼす影響のモニタリングの他、換気されている度合いの指標にもなる。マザーツールのZG106というやつで、買った時点では2万円くらい。上は5万円くらいの製品もあり、下は小型のもので1万円～2万円、間が飛んで安い方では5千円台という状況で、5千円台のものはだいたいが中国製なので、2万円は妥当に信頼できるラインだと思う。
外気のCO2濃度はだいたい400ppmとされていて、オフィス等での環境基準値は1000ppmらしい。自宅では窓を開けていると600ppm前後、窓を閉めて玄関への扉を開けていると800ppm弱、どちらも閉めていると1000～1200ppmになる。
コロナ下で色々と議論はあるものの、Go To トラベルに便乗して飯坂温泉と高湯温泉に行った。感染拡大に貢献するリスクについては観光地では既に折り合いがついていると考えられるし、自分が旅行で感染した場合でも一人暮らしかつ仕事は引きこもりなので、コントロールはしやすい。失うものもないので最悪死んでも痛くなければ……（コロナで死ぬのは結構苦しいっぽいという話は散見するが）。
新幹線に乗るあずにゃん。
宿の食事（ホテル天竜閣）。2泊したけどどれもおいしかった。湯めぐりも入れて8回くらい入浴したと思う。
共同浴場の一つ、鯖湖湯。めちゃくちゃ熱いと聞いていたが、観光客向けに温度が下げられているのか、42～43℃くらいの普通に熱い湯だった（熱いは熱い）。
高湯温泉の玉子湯。
道の駅つちゆの熊笹ソフトとイワナ。熊笹ソフトは抹茶みたいな味だった。笹団子の笹の味と言われればそうでもある。
コロナで色々と難しい面はあるが、他にも旅行に行きたい。
日本に来て自己隔離やアメリカとの調整やらで9月はあっという間に過ぎてしまった。ようやく落ち着いた感があるので、10月はアウトプットを増やしたい。情勢が許すなら旅行もしたい。
2020年の目標 - 8月まとめ
引きこもり生活6ヶ月目。
今月何やったっけ、あんまり覚えてないな。精神があまり上向きにならなかった気がする。
前半はコロナウイルスに支配された世界がどうなるのかを考えていた。人類の根本的な勝利があるとしてもかなり先の話っぽいので、とりあえず直近で日本とアメリカがどうなるか……。データを比べようとしても日本とアメリカ（Austin）の公開しているデータの質が違いすぎてあまりうまく行かなかった。
- https://tsurezure.osak.jp/posts/23
- https://tsurezure.osak.jp/posts/24
- https://tsurezure.osak.jp/posts/25
ただ、少なくとも日本においては政府主導で公衆衛生をどうこうするというよりは個人の意識に任せているように見えたので、本当に社会として致命的な状態にはなっていないんだろうなとは思った。アメリカもさんざん感染爆発とかロックダウンとかしたけどちょっと暴動起こってるくらいで崩壊はしてないしね……。
というわけで9月から日本に行きます。リモートのプログラマなんて世界中どこで働いても同じじゃんというのを感じているので、実際にやってみるとどうなるのかの実験的な意味もある。単に温泉とか行きたいというのもある。とりあえず年明けくらいまで滞在する予定です。
ゲーム。リディー＆スールのアトリエを進めた。調合システムは強い触媒が手に入ると適当に置いてもアイテムが強くなっていくので、最終的には煩雑さはあんまり感じなくなった。ラスボス戦直前になってようやく解禁されるコンビネーションアーツも戦略が広がって面白いし、そもそもグッドエンディング時点で全然錬金レシピも実績も埋まってないので、どう考えてもエンディング後からのやりこみが本番というバランスに調整されているっぽい。グッドエンディング自体は60時間くらいで到達できたけど、これらのエンドコンテンツに見事にハマって、強い武器やアイテムを作りつつパルミナやテルミナと戦ったり、キャライベントを進めたりして、結局80時間くらいプレイした。で、この段階になってトゥルーエンドの条件を満たしていないことが判明したので、今は泣きながらもう1周している（装備品引継ぎと真理特性のおかげで戦闘は超イージーだけど）。2週目はキャラの想いや後の展開が分かっているので、1周目とは違った視点でイベントを見ることができて面白い。
現状のプレイ時間は98時間で、10話の評判上げまで終わった。キャライベントはフラグが立ち次第消化しているので、トゥルーエンドフラグの獲得までもそんなに遠くはない……はず。
あとアトリエの同人誌をいろいろ読み始めたところ、原作と二次創作の境目がよく分からなくなってきた。なんか二次創作っぽい狂った設定も原作が初出だったりして、アトリエは本当にすごい作品だと思う。酸の霧雲で服が溶けるとか、等身大フィリスちゃん人形とか……。
リディスーが終わったらどうしよう。@toshi_aアトリエ診断第3位のトトリでもやるかなぁ。シリーズ1作目からやったほうがいいのかと思いつつ、不思議シリーズ以外ではあんまり作品どうしの繋がりについて熱く語っている人を見ないので、途中からやっても満足できるのかなぁという気がしている。
株。相変わらず見てない。
体重。64.2kg。順調に増えててやばい。運動もしてないしな……。筋肉なさすぎると疲労がめちゃくちゃ溜まるっぽいことに気づいてからは意識的に腕立て伏せとかスクワットとかやってるんだけど、ちゃんと目標管理とかしないとだめなのかな。
新しい技術。技術といっていいのか微妙なラインだけど、業務上でも必要になりつつあるのでコードレビューのやり方についてサーベイしてまとめた（本当にまとめただけ）。
これを元に最強のコードレビュールールを作る予定だけど、仕事のほうが忙しくてやってない。というか仕事で必要なものなので業務時間で書くべきなのでは？そもそも最近適当に昼寝したりして雑な時間に仕事をしているので、時間管理がうまく行ってなくて仕事に時間を割きすぎている気がする。
あと技術という訳でもないが、メモ書き散らしプラットフォームをScrapboxにしてみた。Tsurezureは引退です。やっぱり既製品があるならそっちに乗ったほうがUX良い。
中国語。今月は本当に何もやらなかった。飽きてるのに惰性で続けてもいいことはないので、これで正しいんだとは思う。でもどっかでやる気を復活させないと折角身についた感覚がなくなっちゃいそう。
本。メイドインアビス9巻と紅殻のパンドラ18巻を読んだ。他にも漫画読んだはずだけど読書メーターに記録し忘れてるのでわからんな……。思い出したら登録しとこう。
そういえばDatabase Internalsを読み終えるって言ってて全然進んでないな。8章と9章を読んだ。8章の内容は分散システム概略みたいな感じで、これDesigning Data-Intensive Applicationsで見たやつだ！って思いながら読んでいた。あと用語がちゃんと定義されているのは議論の上でも便利そうなので、Scrapboxにまとめておいた。
来週頭から日本人です。わー久しぶりの日本だーどうなってるんだろうなー。とりあえず入国したら14日間自己隔離なので、おとなしく本でも読み進めたいところ。アメリカで引きこもってても進められてないのに環境変えたくらいで意識が変わるのか？という疑問はともかく……。とりあえずやっていきましょう。
2020年の目標 - 7月まとめ
引きこもり生活5ヶ月目。
どうせフルリモートだし、チームメンバーもいつもより出力速度が遅いので、もっと適当に仕事してもいいんじゃないかと思って勤務時間を勝手にシフトし始めた。だいたい夜のほうが調子がよいので、朝から昼のミーティングに出てコードレビューとかしたら昼寝して、夜にちゃんとコード書いたり面倒な設計とか考えたりする感じで……。あと夜がんばって仕事したら翌日は遅く起きるとか。そもそも眠い時に頑張って起きててもロクな出力は出てこないので寝るのが正しいと思う。
ゲーム。ICFPCやった。アトリエシリーズに敬意を表してチーム名はAtelier Manarimoにした。
今年の問題は盛りだくさんで、序盤は謎の記号列からコンビネータ計算の計算規則を推測するパズル、その次は実際に処理系を書いて与えられたプログラムを実行してGUIを作る、そしてGUI上で実装されたゲームを探索するという、過去のICFPCの面白いエッセンスを抽出したような感じ。24時間が過ぎた後は宇宙空間で宇宙船を操縦してPvPするゲームのAI作りになった（こんな感じのゲーム）。
今年は運営のインフラがかなり良くできていて、インフラ作りが得意な人としてはあんまりやることがなかった。もっとAI作りにアイデア出したりして参加すればよかったなあと思う。前半の解析ゲーはめちゃくちゃ面白かったので、それだけで72時間やっていたかった。
最終提出での上位20チームが決勝ラウンドに選出され、8月のICFP開催時に決勝の結果が発表される。Atelier Manarimoはちゃんと上位20チームには入れたので、決勝でよい結果を出せることを祈っている。打倒Unagi（合言葉）。
もういっこゲーム。ICFPCが終わって暇になったのでリディー＆スールのアトリエを始めた。これでようやく不思議シリーズを制覇できる。今は第7話まで進んだ。アトリエシリーズのNormal難易度はゲームとしてはヌルいことが分かってきたので、最初からHardでやっている。そのおかげかボス戦はなかなか歯ごたえがあった。
イルちゃんが師匠になってるし、落ち着きも増してて感慨がある。フィリスも成長したけど落ち着きがないのは変わってない。ソフィー先生はなんか……伝説みたいになってない？リディーとスーは不思議シリーズのメインキャラとしては珍しく天才タイプじゃないので、錬金術の腕前そのもので壁にぶつかって悩んでいてちょっと新鮮味がある。フィリスのアトリエではソフィーで聞いた曲やアレンジがかかるたびに感動していたけど、今回はイルちゃんやフィリスのテーマに安心感と感慨がある。
錬金システムはちょっと複雑すぎる気がする。錬金成分にめちゃくちゃ種類があっていちいち名前がついてるのはフレーバーとしては面白いし好きだけど、素材選びとなるとマス数に加えて色も吟味しないといけないのが面倒くさい……。触媒の効果も記号が多すぎて選ぶのが面倒なので、いつも適当にミスティックハーブとか入れている。
戦闘システムは面白い。前衛と後衛の組み合わせを考えてうまくコンボが繋がるように悩むのが楽しい。ただ戦闘システムについてゲーム中での説明が少なすぎると思う（後衛はだんだんHPが回復していくとか、ヘルプを読んで初めて知った）。まあ説明書ちゃんと読めってことなんだろうけど……。
ゲームシステムはフィリスを引き継いだまま、シナリオ構成はソフィーのような一本道＋個別キャラシナリオに戻っている。昔のキャラがどんどん出てくるのが楽しいし感慨がある（感慨ばっかり言ってるな）。ただ逆に、ソフィーの時のような新鮮味はちょっと薄れてるかな……。今のところ、良くも悪くも不思議シリーズファンディスクみたいなものという印象。
8/1現在で24時間くらいやっている。これも全クリまで60時間くらいなのかな。
株。見てない。というかあんまり変わってないね。
体重。63.9kgらしい。だんだん増えてるな……。ちょっと真面目に運動を考えないといけなさそう。
新しい技術。ICFPCのために、Tsurezureで培ったRust力を使って簡単なチームポータルサイトを作ったりしていた。結局使わなかったけど。Herokuで有料のDynoやPostgreSQLを使うやつを初めてやった。どちらもめちゃくちゃ簡単にセットアップできて、確かにこれは便利だと思った。
あと、Linuxの環境をちくちくメンテナンスするのが嫌になってきたのと、WSL2が結構いい感じらしいと各所で見聞きするとので、思い切ってメイン環境をWindowsに切り替えた。Linux環境はちゃんと動いている分にはいいんだけど、ちょっと標準から外れた周辺機器とか設定とかを入れようとすると途端にデバイスドライバレベルくらいまで低レイヤの知識が要求されるのがつらい。今のところはmikutterも不自由なく動いているし、プログラミングも特に困ることなくできている。VSCodeのRemote Extensionがとてつもなく良くできていて、WSL2でdocker-composeを動かしながらコンテナ上でVSCodeのRemote extensionを動かし、Windows上で動いてるガワからRemote extensionに繋いで補完も実行もサーバ側でやりつつ表示はWindowsなので高速＆ネイティブのキーバインドで使える、というのが特に複雑な設定をすることなく動いてしまう。Microsoftがこんなに高機能な環境を無料で提供するようになるなんて、十数年前から考えると時代が変わったなあと思う。
中国語。月の初めに数回Ankiをやって、それからモチベーションが尽きてやらなくなってしまった。やっぱり積極的に使う理由がないと、半年くらいがモチベーションの限界という感じがある。
本。芳文社のセールがあったのでいろいろ買った。特に「幸腹グラフィティ」と、同作者（川合マコト）の「甘えたい日はそばにいて」がよかった。緻密な心情描写で作品の中に引き込まれる。特に「甘えたい日はそばにいて」は半端にSFが混ざった恋愛ものという感じの作品で、普通ならこういうのは粗が気になって途中で読むのを諦めてしまうんだけど、この作品はSF考証の粗さをストーリーの良さが大幅に上回っているタイプで、違和感を置いて一気に読んでしまった。
Twitterで流れてきた「うちの師匠はしっぽがない」もよかった。キャラがかわいいのもさることながら、落語というなんとなく知っていそうであんまり知らない距離感の題材が好奇心を刺激する。気力が出たら落語を聞きたい。
本ではないけど、ここ2ヶ月くらいは寝る前ややる気が出ないときにNileRedというYoutubeチャンネルの化学動画を見ている。
いろいろな化学反応を試してみたり、変なものを作ったりする過程をひたすら解説する動画シリーズで、見ているだけでも楽しいし知識欲が満たされる。水銀が絡む反応とか、知識では知っているものの実際に実験で扱ったことはないし、おいそれと試せるものではないのでこういう動画で見られるのは面白い。英語だけど発音がめちゃくちゃきれいだし、何より化学だからだいたい言ってることは推測できるので、リスニングの練習としてもちょうどいい。
9月から日本に逃げようかと思っていたら、7月末から日本でコロナの感染が広がり始めていてちょっとどうしようかと迷っている。旅行が自粛ムードになってるならあんまり日本にいる意味ないし……。地方で新規感染者が出るたび鬼の首を取ったようにバッシングする風潮になっているあたり、あまりコロナウイルスの防疫に関して教育が進んでいるように見えないので、だんだん悪化しそうな気がしている。同じダメならアメリカにいる方が入国後隔離とかもなくて楽だしね……。
最近はちょっと本を読む気力が復活してきたので、8月にはDatabase Internalsを読み終えたいところ。他の目標は追い追い考えていきましょう。
