早起きしてラーメン二郎に開店凸。
関係ないけど、急坂キケンって書くとVOICEROIDの名前みたいでおもしろくないですか。
叡電で出町柳まで下って、川を見る。親子連れが多くてのどかな感じがする。川岸でアレクサに時間を聞いてる子がいておもしろかった。
初めて出町商店街に行った。意外と在学中に行ったことがないと思う。出町ふたばはめちゃくちゃに並んでた。
京都御苑を歩いて帰宅。
早起きしてラーメン二郎に開店凸。
関係ないけど、急坂キケンって書くとVOICEROIDの名前みたいでおもしろくないですか。
叡電で出町柳まで下って、川を見る。親子連れが多くてのどかな感じがする。川岸でアレクサに時間を聞いてる子がいておもしろかった。
初めて出町商店街に行った。意外と在学中に行ったことがないと思う。出町ふたばはめちゃくちゃに並んでた。
京都御苑を歩いて帰宅。
Atom の sunsetting によりエディタ歴を晒す流れが社内で発生してたが,私は HSPスクリプトエディタ -> Terapad -> Eclipse -> NetBeans -> Vim -> Neovim です.
— 🐢 (@ryotakameoka) 2022年6月9日
おもしろいので、思い出せる限りで書いてみます。特定言語向けのIDEは無視しています。上から下に行くほど最近です。
けっこう使ってた気がする。無料版です。シンタックスハイライトに対応している言語が多かったのがよかったと思う。
使ってたことは覚えてるけどあまり記憶がない。このあたりの時期はいろいろなフリーウェアのエディタを使いまくってた気がする。
高校生の頃ぐらいまで使ってたような? 気がする?? このあたりまで記憶が曖昧だし記録も残ってない。
一瞬使ったけど課金せずに終わった。
昔はMeryマクロも書いてた。エディタの機能を拡張したりシンタックスハイライトを追加したりしてた気がする。
GitHubが作った無料のモダンエディタということで使いまくる。その節はお世話になりました。
しばらくgvimで暮らしまくってたと思う。アルバイトのコードもgvimで書いていた。退職に伴ってgvimを使わなくなる。
VS Codeが出てからは基本的にVS Codeしか使わなくなった。
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 } }
いくつかフィールド指定のパターンを変えて試してみたけど、__typename
が "Bar1"
に固定されるし bar1Field
も bar2Field
もoptionalになってしまうケースもある*1。GraphQL Code GeneratorでTypeScriptの型定義ファイルを生成した場合はいずれのケースでも __typename
による絞り込みが効く型が生成された。
relay-compilerを使っている方は気をつけてください。よきコード生成ライフを!
「適切な変更の粒度」について考えることが増えたので、考えていることを流しておきます。
1つのPRでついでにやらない、という話は以前もブログに書いた。コードレビューする側に立っても、このPRでやりたいことが何なのか、目的が達成されている (あるいは未来に達成可能である) かが明瞭だとレビューしやすい。
自分は厳密なConventional Commitsはやってないけど、まず土台を用意して、機能を実装して、ちょっと足りないケースを修正する、みたいな感じで、すくなくともcommit単位で追ったら何がやりたいのかは分かるように気をつけているつもり。
1ファイルずつ、1行ずつ変更していったらそれは差分が小さくなるけど、差分が小さければ小さいほどよい、という話ではないと思う。要はバランスです。
これまでフォーマッタが導入されていなかったプロジェクトにフォーマッタを導入する、という場面を考えてみる。ちょっとずつコードをフォーマットしていると別の変更とコンフリクトしまくることが予想されるので、一気に適用してしまう、という戦略も考えられると思う。
コードフォーマッタじゃないけど、テストフレームワークを入れ替えるときはアルファベット順に数十ファイルずつ入れ替えていく、という戦略を取ったことがある。変更が大きすぎるとコードレビューの負荷が高くなるし、変換スクリプトによる変更にバグがあったときに全ファイルやり直していくことになる、という考えでこうしたと思う。
最短ルート (1行書き換えてcommit) が常に最適とは限らない、ということもある。if文を増やしたときのことを考えてみてください。
id:Sixeight さんのボーイスカウトルールの記事がよかった。自分も圧倒的に先に直す派で、ちょっと難しいタスクをやるために事前に調査してこういうリファクタリングを工程に組み込みます、というのを共有しつつやっている。
最初に作っているうちはまだ仕様が固まっていなかったり、ドメイン知識が足りていなかったのでこう書くしかなかったけど、だんだん全容が見えてきたのでくくり出していく、というのもやっている。
ライブラリのバージョンアップ対応でどうしても大きな非互換変更が必要になるときは、新旧バージョン両方で適用できる実装方法を考えるとか、ライブラリの機能を使っている箇所をラップして互換性を保つとか、そういうことに気をつけられるとよさそう。あとは先まわりしてライブラリのバージョンだけ最新にしておくとか。
マグカップが届いたので早速これでコーラを飲むことにします #はっちゅたぐ pic.twitter.com/6gT23B9iep
— うたがわきき (@utgwkk) 2022年5月27日
以前はタンブラーにコカコーラゼロをなみなみ注いでガブ飲みしてから作業する、という暮らしで、1日2Lのペースでコーラを飲んでいた*1けど、マグカップが届いてからはマグカップでちょっとずつコーラを飲むようになった。コーラを飲みすぎなくなった結果体調がよくなったかは不明で、なぜなら同じ時期にヤクルト1000を飲みはじめたから。対照実験だと思うと失敗している。
使っているマグカップは↓これです。いい絵が入ったマグカップがインターネットで注文できるのはいい時代になったと思う。
一時期はカンファレンスに行くたびにマグカップをもらって、家にどんどんマグカップが増えていた。
*1:1.5Lペットボトルが毎日どんどん空いていく
レビューに参加した「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」*1をご恵贈いただきました。実物が届いたときの感想は「思ったよりも分厚い」でした。
個人的には、ベンチマーカーの書き方の付録 (章ではない!!) が、新鮮な知識が得られるという感じでよかったです。ベンチマーカーに求められる性質や、Go言語を使ったベンチマーカーの実装パターンなど、ISUCONに競技者として参加するだけではなかなか得られない知識が詰まっています。
ISUCONだけでなく、実務でWebアプリケーションのパフォーマンスチューニングをしないといけなくなったけど、どこから確認して何に手をつけたらよいか分からない、という人は必読だと思います。
この本を片手にISUCONに参加して予選を突破できれば最高ですね。今年こそは突破したいです。
*1:通称「ISUCON本」
リアルなフォース、欲しすぎるぜ https://t.co/XSTHQz9EIP
— うたがわきき (@utgwkk) 2022年5月26日
今は英語配列のHHKB Lite2を使っている。2015年の7月に1台目を買っていて、いま使っているのは2台目だけど、実に7年近く同じキーボードを使いつづけていることになりそう。日本語配列のHHKB Lite2を買ったこともあるけど、たしか結局返品したか知り合いに譲ったかした気がする。
たまにキートップが引っかかったり、Shiftキーがずっと押されているような状態になったりすることがあって、そろそろ次のキーボードを買いたいところだった。しかしながら、HHKBの新しいモデルにすると物理の矢印キーがなくなってしまうのが気がかりである。違うキーボードに手を出すことになるか、しかしよく分からないブランドのものだと体験がよいかどうか……と思いつつ暮らしていた。
REALFORCE R3の日本語配列キーボードが出たとき、英語配列はそのうち出る、ということなのでしばらく待っていたが、いつの間にか英語配列も出ていた。次のキーボードとして迎え入れたい。