2022振り返り

去年の振り返りはこちら。

blog.utgw.net

仕事

新卒入社してから携わっていた案件が無事にリリースされた。リリースがゴールではなくて今後もやることはある。

今年の後半になってからは、コミュニケーションとかコードレビューとか、どうやるとうまくいくのか悩むことがしばしばあったと思う。学びを伝える人がいるから、仕事から学びを得られるのだろうか、ということを考えていた。周囲に自分よりもあらゆる面でよくできる人しかいない環境に飛び込むと、もっと変わることがあるのだろうか？

もうすぐ社会人3年目、という感じだけど、新卒入社よりも前に休学フルタイムアルバイトをはさんでいるので時間感覚がわからなくなっている。

そういえばボーナスも無事に出たのでよかったですね。

そういえば (2) 会社の納会で賞をもらっていたのを思い出した。これもよかったですね。

賞もらった

— うたがわきき (@utgwkk) 2022年1月31日

同人誌

今年は夏コミ (C100) で同人誌を出した。

blog.utgw.net

同人誌を書いたのが直接のきっかけなのか、create-react-appに関する調査をよく行っていたのが先なのかは覚えていないけど、Webフロントエンドのツールチェーンへの理解を深めることができたと思う。

ゲーム

去年に引き続きブルアカをやりつつ、スプラトゥーン3が発売されてからはずっとシャケをしばいていた。

ブルアカは、エデン条約編の完結を見届けられたのがよかった。最後まで聖園ミカという少女に振り回されながらストーリーを読み進めることになった。スプラトゥーン3が出たので最近はやや停滞気味。

サーモンランはぼちぼちやっています。でんせつ帯で一喜一憂するのが日常になっている。

旅行

今年はなぜか東京にいることが多かったと思う。目当てのコンテンツが東京でイベントをやることが多いのでそういうものか？ 東京に来るたびに東京の友だちと飲みに行ける、というのも大きそう。

RubyKaigiで三重に行けたのはよかった。こういうカンファレンスで普段なかなか行かないところに行く感覚を徐々に思い出しつつある。

blog.utgw.net

住居

引っ越しから1年が経った。

blog.utgw.net

いろいろ買い揃えてだいたい落ち着いてきたように思う。前の家と違って収納スペースがあるし、そもそも部屋も広くなっているから窮屈感もなくリモートワークもできている。

当分は引っ越す気持ちがなくて、更新料も払うことになると思う。もっと広くて設備の整った家だといろいろ可能性が広がるのかもしれないけど、ひとまずこれぐらいで不自由していない。明確にグレードを上げると、家賃が上がるか、立地を諦めるかということになりそう。

2023年に向けて

来年の抱負について考えてみたけどやめた。のらりくらり暮らしているであろう……。ひきつづき京都にはいると思うので飲みに行きましょう。

自作したpytestプラグインをpytest-dev organizationに移管した

これは KMC Advent Calendar 2022 - Adventar 20日目の記事です。昨日の記事は コンテナ詰め詰め大作戦2022冬 - (｡･ω･｡)ノ･☆':*;':* でした。

---

pytest-github-actions-annotate-failuresという、GitHub Actionsで落ちたテストにアノテーションするpytestプラグインをpytest-dev GitHub organizationに移管しました。

github.com

移管するに至った直接のきっかけは、このプラグインをpytest-devでホストしませんか、というissueが起票されたことです。

github.com

このプラグインは、自分では今のところ個人開発でしか使っていません。しかしながら、世間にはOSSや業務で使っている人もいるのであろう、メンテナンスに飽きて放棄されるよりはそれらしいorganization下にあるほうがいいだろう、と思って移管を進めることにしました。いろいろやっていたら1年以上待たせてしまうことになりましたが、無事にプラグインを移管することができました。

プラグインをpytest-dev organizationに移管する方法はシンプルです。移管するプラグインの必須要件に従った上でpytest-dev/metaにissueを起票し、反対がなければ移管を進める、という流れになります。どれも難しい要件ではないのですが、CIのテストをtoxで走らせるのだけ少し用意が必要でした。

プラグインの移管に成功したので、早速PyPIのホームページのURLを変えようとしたら、CIが壊れていました。助言をもらいながらCIを直して、無事にURLを修正したバージョン0.1.8をリリースすることができました。

もともとこのプラグインは、GitHub Actionsのアノテーション機能を活用したpytestプラグインとして高速に作って出したのでした。それがいつの間にかいろいろなリポジトリで使われており、Project templateの一部として紹介されるなどもあって、なんだか不思議な感じです。個人の名前よりはそれらしいorganization下に移すことができて、収まるところに収まった感じがあります。

---

KMC Advent Calendar 2022 - Adventar 明日の担当は koh くんで、芸大に4年通った振り返りと自身の制作まとめ - koh90のブログ でした。

Perl::Critic::Policy::Subroutines::ProhibitBuiltinHomonyms で許可する識別子を設定できるようになった

これは Perl Advent Calendar 2022 13日目の記事です。昨日の記事は Perlで戻り値として呼び出した子サブルーチンのコンテキストは親と同じ - hogashi.* でした。

perlcriticは、Perl向けのlinterです。詳しくは以下の記事などを参照してください。

blog.utgw.net

perlcriticの組み込みポリシー*1の1つに Subroutines::ProhibitBuiltinHomonyms があります。これは、Perlの組み込みサブルーチンや予約語と同じ名前のサブルーチンの定義を禁止するポリシーです。podから引用すると、以下のようなサブルーチン定義がポリシー違反だとみなされます。

sub open {}    #not ok
sub exit {}    #not ok
sub print {}   #not ok
sub foreach {} #not ok
sub if {}      #not ok

ところで、サブルーチンを使ってコントローラー定義するときは sub index や sub delete のような名前で定義するほうが意味が伝わりやすいこともあるかもしれません。これまでは、perlcriticの警告を抑制するためにいちいち ## no critic コメント*2を書く必要がありました。しかし、もうちょっと設定の余地があってほしいものです。

ということで、Subroutines::ProhibitBuiltinHomonyms ポリシーが許可する識別子を設定できるようにするPRを (2年前に) 作り、つい先日取り込まれました。perlcriticの次のリリースではきっと設定項目が増えていると思います。

github.com

---

2023/1/6 追記: 当該の設定項目が perlcritic 1.146でリリースされました。

Subroutines::ProhibitBuiltinHomonyms now can take an "allows" parameter to specify subroutines that won't violate the policy. Thanks, UTAGAWA Kiki. (GH #14, #932) https://metacpan.org/release/PETDANCE/Perl-Critic-1.146/source/Changes#L12-14

---

PPI*3でPerlの構文木を触ったことがある人なら、比較的簡単にperlcriticにコントリビュートできると思います。みなさまも既存のポリシーに不満があれば、設定項目を足したり新しいポリシーを作ったりしてみてはいかがでしょうか。

明日は id:sfujiwara さんです。

*1:ESLintのルールに相当します

*2:eslint-disable コメントに相当します

*3:Perlプログラムをパースするライブラリ

Recoilとwebpack.DefinePluginと環境変数の名前

これは React Advent Calendar 2022 7日目の記事です。

Recoilを使っているアプリケーションでWebpackのDefinePluginを使って環境変数の値をビルド時に埋め込むとき、Webpackの設定によっては環境変数の名前がビルドしたコードに含まれてしまう場合があります。

具体的には、以下のようにDefinePluginの process.env キーに対してobjectを渡す場合に発生しえます。

new webpack.DefinePlugin({
  'process.env': {
    FOO: JSON.stringify(process.env.FOO),
  },
});

ここでRecoilのコードを見てみましょう。ランタイムに process.env の値を参照するコードがあるのに気づくと思います。

github.com

optional chainingをトランスパイルすると、ビルド成果物内の process.env という式がDefinePluginにより {FOO: JSON.stringify(環境変数FOOの値)} というオブジェクトに置換されます。DefinePluginに process.env.FOO といったキーで環境変数の値を渡した場合は埋め込まれません。

Webフロントエンドアプリケーションのビルド時に環境変数の値を埋め込む際には気をつけましょう。DefinePluginの設定を見直したり、あるいは環境変数の名前として外部に露出しても支障のないものにしたりなど……。

2022/12/7 23:39 追記

Recoilとwebpack.DefinePluginと環境変数の名前 - 私が歌川です

• [webpack]

process.env で置換すると実行時に差し込まれる環境変数も巻き込まれてしまうので、そういう意味でも process.env.FOO 形式じゃないと駄目そう。EnvironmentPlugin という専用のものがあってそっちがオススメです。

2022/12/07 23:21

b.hatena.ne.jp

EnvironmentPluginは初めて知りました。明らかにDefinePluginで環境変数を差し込むユースケースを代替することが意図されていてよさそうですね。

The EnvironmentPlugin is shorthand for using the DefinePlugin on process.env keys.

webpack.js.org

年末恒例・大sketchリポジトリ棚卸祭

はじめに

これは はてなエンジニア Advent Calendar 2022 6日目の記事です。昨日は id:momochi29 さんで「口癖を自動で検出する手法」でした。口癖って自分ではなかなか気づけないですよね。

tjmtmmnk.hatenablog.com

アプリケーションエンジニアの id:utgwkk です。今年作ったsketchリポジトリについてお話ししようと思います。年末恒例というのはたった今考えました。

sketchリポジトリとは

みなさまは、ちょっとしたコードを書いて実験したくなったことがありますか？ 私はそういったとき、GitHubに sketch-yyyymmdd-abcdefg のような日付入りの名前のリポジトリを作って実験に使ったコードをpushしておくことが多いです。そのようにして作られたリポジトリのことをsketchリポジトリと呼ぶことにします。

要するに、書き捨ての実験用のコード置き場のことです。

大放出

今年中 (2022/1/1-2022/12/5) に作ったsketchリポジトリについて振り返り、思い出を語っていこうと思います。

20220313-sketch-docker-compose-python

以下の記事での調査用に作ったリポジトリです。Docker Compose v2を使うとpytestのログ出力が一切行われない、という現象の調査をこのリポジトリで行っていました。癖で docker-compose というコマンドを実行しつづけていたら気づかない不具合というのがおもしろポイントだと思います。

blog.utgw.net

20220324-sketch-css-webfont-unicode-range

以下の記事の検証のために作ったリポジトリです。この記事は前提から実験内容まで丁寧に書いてあってすごいですね。

blog.utgw.net

202204017-sketch-webpack-sourcemap

Webpack (create-react-app) のバージョンアップとそれに伴うsourcemap周りの挙動変化の調査のために作ったリポジトリです。日付部分がtypoしていることにいま気づいた……。

create-react-appのバージョンを上げたら特定のライブラリのsourcemapに関する警告が出るようになった、というのを調査していて、どうやらWebpack周りが怪しそうということでWebpackの設定を手書きしています。

20220606-sketch-graphql-type-emission

relay-compilerが生成するコードとGraphQLクエリの関係について調査するために作ったリポジトリです。話題としては以下の記事が近いと思います。振り返ってみると、1年おきに型生成に関する罠を踏み抜いている感じがしておもしろいですね。

blog.utgw.net

blog.utgw.net

20221024-sketch-node18-fetch-jest

Node.js 18では fetch 関数がデフォルトで使えるようになるけど、フロントエンドのテスト (jsdomの環境下) でも使えるのかどうか、を検証するのに使ったリポジトリです。

結論から言うと、2022/12/5時点では fetch はフロントエンドのテストでは使えないので、ひきつづきモックする必要があります。以下のissueで言及されているように、Node.jsの組み込みの fetch 関数ではない標準規格に準拠した関数をjsdom側で用意する必要がある (のでNode.js 18に上げてもjsdomの環境下で fetch 関数が使えるようにはならない)、というスタンスのようです。

github.com

20221117-sketch-react-modal

react-modalを使ったモーダル内の読み上げテキストがおかしい (意図しない要素が2回読み上げられる)、という問題の調査に使ったリポジトリです。iOSの読み上げコンテンツ機能を使ったときのみ再現するので、iOSのバグでは？ という見立てをしています。

おわりに

書き捨てのコードというと、以前はGitHub Gistに上げることが多かったと思いますが、最近はリポジトリを作ってしまうほうが便利なことが多い*1と思います。また、コードを共有しておくと議論がスムーズになるとか再現してもらいやすいということで、どんどんお試しリポジトリが増えていきます。みなさまも、気になることがあったらお試しリポジトリにコードを置いてサクッと試してみてはいかがでしょうか。

明日の担当は id:yigarashi さんです。

*1:CIが動かせる、ディレクトリが作れる、などなど

できるだけ自然言語として読めるように書く

……というのが今年の個人的なキーフレーズだったのかもしれない、とふと思った。そういうキーフレーズに対してどういう取り組みをしてきたのか、ここで振り返ってみる。やってみたらあまりオチがない感じだった。

自然に読み下せるように書く

「setNewValue 関数に val 変数を渡す」と「setNewValue(val) する」だと前者のほうが好ましいと思う。文脈から読み方を想像してもらうよりは、明示的に書いてあって自然に読み下せるようになっているほうがありがたい。あるいは、インラインコードに思いを込めすぎないようにする、とも言い表せるのかもしれない。

文章のつながりを意識する

文の羅列があって、それではこれを読んでください、という態度だとなかなか伝わらないと思う。使っているツールにもよるけど、見出しや箇条書きをうまく使うようにするとか、接続詞をちゃんと使うとか、そのあたりを気をつけるとよさそう。

あとは、前提・結論・感想・意見などがごちゃごちゃになっているよりは、はっきり分かれているほうがいい。このあたりは「理科系の作文技術」を読んでもらうのがよさそう。連日同じ本の話をしている気がする。

理科系の作文技術（リフロー版） (中公新書)

言語化を厭わない

例えば、ちょっといまいちな実装があったとして、「この実装はいまいちですね」というレビューコメントを付けても、レビュワーにとってはどうしたらいいのか分からないと思う。何がどういまいちなのかを噛み砕いて言葉にした上でコメントを付けるようにする。「一貫性がなくなっている」「責務が大きすぎる」など、「いまいち」という言葉で済ませないように心がけている。

(細かい) 綴りには気をつける

細かいけど、英単語やコードネームなどの綴りが間違っていると、一見してそっちに気を取られてしまう。すくなくとも自分が書くときはできるだけ綴りを間違えないように書いていきたい。

■

ChatGPTでAIとおしゃべりブームが来ている。来ているというか、ひと通り見たので次のAIブームが来たらまた野次馬に来ます、という感じ。いまのところ娯楽としてはおもしろいと思う。

知っている単語と単語をつなげて、構文的にはつながっているけどまったく正しくない文が出てくるのを見ると、まだまだ改善の余地があると思う。知らないことをさも知っているかのように答えてください、分からないはナシです、と言われたら自分もこのように振る舞わざるを得ないのだろうか。知らないことは知らないから知らないとしか言えないと思う。

生身の人間がこのような受け答えをしているほうが厄介だなと思ったけど、自分の学部時代のレポートも似たようなものだったのではないか。一生懸命調べてまとめた結果がそうである、という違いはあるかもしれない。つまり、文章を書いて相手に伝える機会が多いといい、ということが言いたいのであった。

ここで一冊

理科系の作文技術（リフロー版） (中公新書)

blog.utgw.net