私が歌川です

@utgwkk が書いている

休日

早起きしてラーメン二郎に開店凸。

関係ないけど、急坂キケンって書くとVOICEROIDの名前みたいでおもしろくないですか。

叡電で出町柳まで下って、川を見る。親子連れが多くてのどかな感じがする。川岸でアレクサに時間を聞いてる子がいておもしろかった。

初めて出町商店街に行った。意外と在学中に行ったことがないと思う。出町ふたばはめちゃくちゃに並んでた。

京都御苑を歩いて帰宅。

エディタ歴

おもしろいので、思い出せる限りで書いてみます。特定言語向けのIDEは無視しています。上から下に行くほど最近です。

EmEditor

けっこう使ってた気がする。無料版です。シンタックスハイライトに対応している言語が多かったのがよかったと思う。

サクラエディタ

使ってたことは覚えてるけどあまり記憶がない。このあたりの時期はいろいろなフリーウェアのエディタを使いまくってた気がする。

TeraPad

高校生の頃ぐらいまで使ってたような? 気がする?? このあたりまで記憶が曖昧だし記録も残ってない。

Sublime Text

一瞬使ったけど課金せずに終わった。

Mery

昔はMeryマクロも書いてた。エディタの機能を拡張したりシンタックスハイライトを追加したりしてた気がする。

blog.utgw.net

Atom

GitHubが作った無料のモダンエディタということで使いまくる。その節はお世話になりました。

blog.utgw.net

vim (gvim)

しばらくgvimで暮らしまくってたと思う。アルバイトのコードもgvimで書いていた。退職に伴ってgvimを使わなくなる。

Visual Studio Code

VS Codeが出てからは基本的にVS Codeしか使わなくなった。

relay-compilerでinline fragmentのある型定義を生成するときのコツ

relay-compiler 13.2.0で確認した。つい昨日にRelay 14が出ていたので試してみたけど同様の結果になった。

特定のinterfaceに対するinline fragment内に、interfaceが共通して持つフィールドも都度列挙して書くと、直和型の __typename フィールドによる型の絞り込みが効くようになる。逆に、共通して持つフィールドをinline fragmentの外に書くと、型の絞り込みが効かなくなる。

# OK: __typenameによる絞り込みが効く
fragment Foo_bar_ok on Bar {
  ... on Bar1 {
    __typename
    barField
    bar1Field
  }
  ... on Bar2 {
    __typename
    barField
    bar2Field
  }
}

# NG: __typenameで型を絞り込めず、bar1Field, bar2Fieldが常にoptionalになってしまう
fragment Foo_bar_ng on Bar {
  barField
  ... on Bar1 {
    __typename
    bar1Field
  }
  ... on Bar2 {
    __typename
    bar2Field
  }
}

github.com

いくつかフィールド指定のパターンを変えて試してみたけど、__typename"Bar1" に固定されるし bar1Fieldbar2Field もoptionalになってしまうケースもある*1。GraphQL Code GeneratorでTypeScriptの型定義ファイルを生成した場合はいずれのケースでも __typename による絞り込みが効く型が生成された。

relay-compilerを使っている方は気をつけてください。よきコード生成ライフを!

「適切な変更の粒度」とは何なのか

「適切な変更の粒度」について考えることが増えたので、考えていることを流しておきます。

関連する変更がまとまってると嬉しい

1つのPRでついでにやらない、という話は以前もブログに書いた。コードレビューする側に立っても、このPRでやりたいことが何なのか、目的が達成されている (あるいは未来に達成可能である) かが明瞭だとレビューしやすい。

blog.utgw.net

自分は厳密なConventional Commitsはやってないけど、まず土台を用意して、機能を実装して、ちょっと足りないケースを修正する、みたいな感じで、すくなくともcommit単位で追ったら何がやりたいのかは分かるように気をつけているつもり。

小さければ小さいほどよい、とは限らない

1ファイルずつ、1行ずつ変更していったらそれは差分が小さくなるけど、差分が小さければ小さいほどよい、という話ではないと思う。要はバランスです。

これまでフォーマッタが導入されていなかったプロジェクトにフォーマッタを導入する、という場面を考えてみる。ちょっとずつコードをフォーマットしていると別の変更とコンフリクトしまくることが予想されるので、一気に適用してしまう、という戦略も考えられると思う。

コードフォーマッタじゃないけど、テストフレームワークを入れ替えるときはアルファベット順に数十ファイルずつ入れ替えていく、という戦略を取ったことがある。変更が大きすぎるとコードレビューの負荷が高くなるし、変換スクリプトによる変更にバグがあったときに全ファイルやり直していくことになる、という考えでこうしたと思う。

scrapbox.io

最短ルート (1行書き換えてcommit) が常に最適とは限らない、ということもある。if文を増やしたときのことを考えてみてください。

ところでリファクタリング

id:Sixeight さんのボーイスカウトルールの記事がよかった。自分も圧倒的に先に直す派で、ちょっと難しいタスクをやるために事前に調査してこういうリファクタリングを工程に組み込みます、というのを共有しつつやっている。

blog.nishimu.land

最初に作っているうちはまだ仕様が固まっていなかったり、ドメイン知識が足りていなかったのでこう書くしかなかったけど、だんだん全容が見えてきたのでくくり出していく、というのもやっている。

ライブラリのバージョンアップ対応でどうしても大きな非互換変更が必要になるときは、新旧バージョン両方で適用できる実装方法を考えるとか、ライブラリの機能を使っている箇所をラップして互換性を保つとか、そういうことに気をつけられるとよさそう。あとは先まわりしてライブラリのバージョンだけ最新にしておくとか。

マグカップでコーラを飲んでいる

以前はタンブラーにコカコーラゼロをなみなみ注いでガブ飲みしてから作業する、という暮らしで、1日2Lのペースでコーラを飲んでいた*1けど、マグカップが届いてからはマグカップでちょっとずつコーラを飲むようになった。コーラを飲みすぎなくなった結果体調がよくなったかは不明で、なぜなら同じ時期にヤクルト1000を飲みはじめたから。対照実験だと思うと失敗している。

使っているマグカップは↓これです。いい絵が入ったマグカップがインターネットで注文できるのはいい時代になったと思う。

hachun.booth.pm

一時期はカンファレンスに行くたびにマグカップをもらって、家にどんどんマグカップが増えていた。

*1:1.5Lペットボトルが毎日どんどん空いていく

ISUCON本を頂きました

レビューに参加した「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」*1をご恵贈いただきました。実物が届いたときの感想は「思ったよりも分厚い」でした。

個人的には、ベンチマーカーの書き方の付録 (章ではない!!) が、新鮮な知識が得られるという感じでよかったです。ベンチマーカーに求められる性質や、Go言語を使ったベンチマーカーの実装パターンなど、ISUCONに競技者として参加するだけではなかなか得られない知識が詰まっています。

ISUCONだけでなく、実務でWebアプリケーションのパフォーマンスチューニングをしないといけなくなったけど、どこから確認して何に手をつけたらよいか分からない、という人は必読だと思います。

この本を片手にISUCONに参加して予選を突破できれば最高ですね。今年こそは突破したいです。

*1:通称「ISUCON本」

リアルなフォース

今は英語配列のHHKB Lite2を使っている。2015年の7月に1台目を買っていて、いま使っているのは2台目だけど、実に7年近く同じキーボードを使いつづけていることになりそう。日本語配列のHHKB Lite2を買ったこともあるけど、たしか結局返品したか知り合いに譲ったかした気がする。

blog.utgw.net

たまにキートップが引っかかったり、Shiftキーがずっと押されているような状態になったりすることがあって、そろそろ次のキーボードを買いたいところだった。しかしながら、HHKBの新しいモデルにすると物理の矢印キーがなくなってしまうのが気がかりである。違うキーボードに手を出すことになるか、しかしよく分からないブランドのものだと体験がよいかどうか……と思いつつ暮らしていた。

REALFORCE R3の日本語配列キーボードが出たとき、英語配列はそのうち出る、ということなのでしばらく待っていたが、いつの間にか英語配列も出ていた。次のキーボードとして迎え入れたい。