帰省することもなく、初詣はいちおうやったからいいか、ということでのんびり寝正月。学生の頃と違って、締切に追われることもなくゆったり過ごしている。
1/4に有休を入れたので、仕事始めは1/5になる。年末にいろいろな通知を切ったし、有休を入れたぶんのキャッチアップもあるので、明後日はやることがそれなりにありそう。
帰省することもなく、初詣はいちおうやったからいいか、ということでのんびり寝正月。学生の頃と違って、締切に追われることもなくゆったり過ごしている。
1/4に有休を入れたので、仕事始めは1/5になる。年末にいろいろな通知を切ったし、有休を入れたぶんのキャッチアップもあるので、明後日はやることがそれなりにありそう。
元旦から電電宮と伏見稲荷大社をまわって、なかなか元気があった。
電電宮のお守りとシールを買って、エジソンとテスラの霊に祈りを捧げたのであった。電電宮のシールはいくつ買ってもいい。なぜなら、いつの間にか消滅するから。
嵐山から電車がちょうどよく出るので、そのまま伏見稲荷に向かった。お守りを更新したら満足してきた。伏見稲荷にはスズメの肉を食べられる店があるのだけど、人が多すぎるのでオフシーズンにふらっと行きたい。
メロンブックスでC101の新刊をちょっと眺めた。委託で買うとどうしても割高に見える。けどそういうものだと思う。
お雑煮と称して賞味期限切れの食料を消費しようとした。元旦はスーパーも閉まってるのでコンビニに頼ることになる。帰省したら自動的に料理が出てくるのだろうけど、ここ数年は帰省の機運がない。
年明け初のサーモンランをやったら難しい編成でなかなか大変だった。
去年の振り返りはこちら。
新卒入社してから携わっていた案件が無事にリリースされた。リリースがゴールではなくて今後もやることはある。
今年の後半になってからは、コミュニケーションとかコードレビューとか、どうやるとうまくいくのか悩むことがしばしばあったと思う。学びを伝える人がいるから、仕事から学びを得られるのだろうか、ということを考えていた。周囲に自分よりもあらゆる面でよくできる人しかいない環境に飛び込むと、もっと変わることがあるのだろうか?
もうすぐ社会人3年目、という感じだけど、新卒入社よりも前に休学フルタイムアルバイトをはさんでいるので時間感覚がわからなくなっている。
そういえばボーナスも無事に出たのでよかったですね。
そういえば (2) 会社の納会で賞をもらっていたのを思い出した。これもよかったですね。
賞もらった
— うたがわきき (@utgwkk) 2022年1月31日
今年は夏コミ (C100) で同人誌を出した。
同人誌を書いたのが直接のきっかけなのか、create-react-appに関する調査をよく行っていたのが先なのかは覚えていないけど、Webフロントエンドのツールチェーンへの理解を深めることができたと思う。
去年に引き続きブルアカをやりつつ、スプラトゥーン3が発売されてからはずっとシャケをしばいていた。
ブルアカは、エデン条約編の完結を見届けられたのがよかった。最後まで聖園ミカという少女に振り回されながらストーリーを読み進めることになった。スプラトゥーン3が出たので最近はやや停滞気味。
サーモンランはぼちぼちやっています。でんせつ帯で一喜一憂するのが日常になっている。
今年はなぜか東京にいることが多かったと思う。目当てのコンテンツが東京でイベントをやることが多いのでそういうものか? 東京に来るたびに東京の友だちと飲みに行ける、というのも大きそう。
RubyKaigiで三重に行けたのはよかった。こういうカンファレンスで普段なかなか行かないところに行く感覚を徐々に思い出しつつある。
引っ越しから1年が経った。
いろいろ買い揃えてだいたい落ち着いてきたように思う。前の家と違って収納スペースがあるし、そもそも部屋も広くなっているから窮屈感もなくリモートワークもできている。
当分は引っ越す気持ちがなくて、更新料も払うことになると思う。もっと広くて設備の整った家だといろいろ可能性が広がるのかもしれないけど、ひとまずこれぐらいで不自由していない。明確にグレードを上げると、家賃が上がるか、立地を諦めるかということになりそう。
来年の抱負について考えてみたけどやめた。のらりくらり暮らしているであろう……。ひきつづき京都にはいると思うので飲みに行きましょう。
これは KMC Advent Calendar 2022 - Adventar 20日目の記事です。昨日の記事は コンテナ詰め詰め大作戦2022冬 - (。・ω・。)ノ・☆':*;':* でした。
pytest-github-actions-annotate-failuresという、GitHub Actionsで落ちたテストにアノテーションするpytestプラグインをpytest-dev GitHub organizationに移管しました。
移管するに至った直接のきっかけは、このプラグインをpytest-devでホストしませんか、というissueが起票されたことです。
このプラグインは、自分では今のところ個人開発でしか使っていません。しかしながら、世間には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 Advent Calendar 2022 13日目の記事です。昨日の記事は Perlで戻り値として呼び出した子サブルーチンのコンテキストは親と同じ - hogashi.* でした。
perlcriticは、Perl向けのlinterです。詳しくは以下の記事などを参照してください。
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の次のリリースではきっと設定項目が増えていると思います。
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 さんです。
これは 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
の値を参照するコードがあるのに気づくと思います。
optional chainingをトランスパイルすると、ビルド成果物内の process.env
という式がDefinePluginにより {FOO: JSON.stringify(環境変数FOOの値)}
というオブジェクトに置換されます。DefinePluginに process.env.FOO
といったキーで環境変数の値を渡した場合は埋め込まれません。
Webフロントエンドアプリケーションのビルド時に環境変数の値を埋め込む際には気をつけましょう。DefinePluginの設定を見直したり、あるいは環境変数の名前として外部に露出しても支障のないものにしたりなど……。
Recoilとwebpack.DefinePluginと環境変数の名前 - 私が歌川ですb.hatena.ne.jp
- [webpack]
process.env で置換すると実行時に差し込まれる環境変数も巻き込まれてしまうので、そういう意味でも process.env.FOO 形式じゃないと駄目そう。EnvironmentPlugin という専用のものがあってそっちがオススメです。
2022/12/07 23:21
EnvironmentPluginは初めて知りました。明らかにDefinePluginで環境変数を差し込むユースケースを代替することが意図されていてよさそうですね。
The EnvironmentPlugin is shorthand for using the DefinePlugin on process.env keys.