YAPC::Kyotoの思い出 #yapcjapan

こんにちは。そろそろ京都に引っ越して3年のid:anatofuzです。

先日のYAPC::Kyotoではスタッフをしていました

yapcjapan.org

コアスタッフではあるものの、昨年末から今年にかけて引っ越しがあったり、本業の仕事もなかなか大変で平日は仕事をしてそれ以外のことができない、土日は疲労という感じで身動きが取れない、様々なことが発生してメンタルも死*1という状況が数ヶ月続いてしまい、あまり準備にコミットすることができませんでした。ここはid:papixさんはじめスタッフの皆さんに非常に申し訳なく思っています。

その分準備と当日のスタッフ業こそはちゃんとやろうとしていて、当日は土俵の部屋番長をやっていました。主にslack/twitterで状況を確認しつつ、タイムキープをしながらメンバーと連携していく係です。土俵のスタッフのid:tomcha0079さん、id:nhayatoさん、id:kaoru1615くん方のおかげではあるのですが、スケジュール通りで大変な問題も発生せずに無事おえられて何よりでした。

基本的にはそういったスタッフ業が中心であんまりカンファレンス中は人々と話したりするのがバタバタしていてできなかったのですが、数年ぶりにid:codehex先輩とあったり、大学の戦友のid:unimarimoやPerl入学式方面やYAPC::Okinawaでの思い出深いid:note103さん、ずっと憧れであったゆーすけべーさんとお会いすることができて、自分が好きだったYAPC、コミュニティにまた復帰できた感じがしました。特に土俵でトークしていただいたid:ar_tamaさんは、Okinawa.pmでやったYAPC::Okinawaの立ち上げのときに知り合ったこともあり、あらたまさんとYAPCの関連がすごく印象に残っていて、そんなあらたまさんがちょうど自分が今悩んでいたエンジニアのキャリアについて眼の前でトークされているのは、まさにYAPCだな....という感じで感無量でした。

個人的には今回のYAPCではちょっとだけ、恩を返せたかなという出来事がありました。 学生時代にPerlコミュニティの支援でPerlConに参加させていただいたのですが、今回はその支援カンパの余剰分のうちの一部*2を学生支援スポンサーメインのスポンサーとして協力させていただきました。

会社という訳ではないので金額等柔軟に対応していただいたid:papixさんには感謝です。*3

anatofuz.hatenablog.com

個人的にはスポンサーして無事学生さんの旅費を支援できて満足という感じだったのですが、忘れていたスポンサーチケットを、ちょうど学生チケットの購入を逃してしまった学生さんにお譲りすることができることなどがあり、そういう意味でも今までコミュニティからもらえた恩を少し返せたかなとは思っています。

あとは沖縄から学科の後輩のid:e205723とid:mattari_matayuをYAPC::Kyotoに呼べたのが良かったかなと思っています。沖縄のPerlコミュニティにお世話になったので、沖縄の人々にもどうにかしておきたかった。

次回はYAPC::Hiroshimaになりそうな気配がありますが、個人的に地元の山梨でYAPCをやるまではやっていくぞという感じでもあり、今回あまりコミットできなかった分次はやっていきたいので、次回は広島でまたお会いしましょう。よろしくお願いします。

*1:引っ越しで貯金が無くなったり、京都に引っ越してから数年物理的に旧友とあってなかったり、仕事のコードばかりでテンションが上がる趣味のコードがかけなかったり

*2:20万ほど。残りはまたYAPCで使います

*3:スポンサー一覧に載せなかったのはなんか個人的に自分のアイコン乗せるのもな...というところです

PerlにおけるGraphQLライブラリのまとめ

Perl

リッチなフロントエンドを開発しているとGraphQLを使いたくなるときがあり、さらにそのバックエンドをPerlで実装したくなるときもあるでしょう。

このエントリではPerlでGraphQL開発をしたい時に使える2023/02/24現在のPerlのGraphQL周りのライブラリ事情についてまとめます。

GraphQLフレームワーク

graphql-perl

PerlでCPANモジュールを使ってGraphQLバックエンドを実装したいとなった場合に現状コレ一択。

PerlCareersの支援で資金援助を受けて実装されている。

世界観としてはThis module is a port of the GraphQL reference implementation, graphql-js, to Perl 5.と言っているが、graphql-jsの忠実な移植ではなく、限りなく処理を独自実装しているのが特徴。

MooやType::TinyなどのモダンPerl的なライブラリをふんだんに使っていたり、GraphQLのパースをPegex::Parserを使い正規表現を用いて行っている。

やや実装に難がありパフォーマンスに問題が発生しがちな傾向にある。

khrt/graphql-perl

graphql-jsの忠実な移植プロダクト。 残念ながら開発が途中で止まっていそう。

stevan/p5-Graph-QL

khrt/graphql-perlと同様にgraphql-jsの忠実な移植。 開発が5年で止まって入るが、比較的実装されている。

パーサーライブラリ

GraphQL::Language::Parser

前述のgraphql-perlの一部分

Parser::GraphQL::XS

graphql公式のリポジトリにあるC++で実装されたGraphQLパーサー( https://github.com/graphql/libgraphqlparser )のXSバインダ。

ただしParser::GraphQL::XSにはlibgraphqlparserをインストールするみたいなおもてなしが無いことから、このモジュールをインストールする際は自前でlibgraphqlparserをインストールする必要がある。

DataLoader

GraphQLでクエリに対するSQLをいい感じにまとめる時に使われる機能であるDataLoaderの参考実装。 Mojoliciousが動いていることが前提となっているため、Mojoliciousを使っていないwebアプリケーションには直接組み込めない

というわけで基本graphql-perlを使えば良いのだけど、graphql-jsの素朴な移植もほしいですね。。。

Perlでスマートに配列からランダムで特定個数の値を取得する

Perl

TL;DR

use List::Util qw(sample);

my @array = (1..100);
# 3個ランダムでとりだす

my @random_pickup = sample 3, @array;

人間生きていると配列の中身からランダムにn個取得したいときがあります。Perl書いているときもありますね。

よくある方法は次のような感じでしょうか

my @array = (1..100);
my @random_array =  shuffle @array ;
my @random_pickup  = splice @random_array, 0, 3;

List::Utilのshuffleを使い配列をランダムにばらしたあとに、標準関数のspliceを使い特定の数の値を取り出してきます。 これだと@random_pickupには3つのランダムな数が入る訳ですね。

ただしこの方法だと必ず全件をshuffleしないといけないため、巨大な配列を対象にする場合はそこそこコストが掛かります。 他には結局@random_pickupが必要な場合は、中間変数の@random_arrayが不必要ですね。 (最も、工夫すれば中間変数を作らずにかけますが...)

そこでオススメなのがList::Utilのsample関数です。1.54から同梱されているので、比較的最近のList::Utilになら入っています。 ちなみにList::MoreUtilsにも入っています。

書き方は簡単で以下の感じです。

my @items = sample $count, @values; # sample {取得したい数}、 {リスト}

$countが@valuesの配列長より大きい場合は、shuffleと同じ挙動になります。

近年のList::UtilはXS(C言語実装)も同梱されており、sampleも見てみるとC言語レベルで特定個数のランダム取得をしてくれています。 このため、コスト的にもshuffleしてからspliceなどで取得するより最適化されておりオススメです。 metacpan.org

2022年、CPAN(Perlの)モジュールのメンテナを引き継ぐ活動を始めた件

Perl

これははてなエンジニアアドベントカレンダー2022 42日目の記事です。 昨日は id:k-murakami0609 さんの 過去に所属してたチームに転生したら導入したいもの でした。

はてなのノベルチームで日常的に使っている便利グッズ最高ですね!! みなさんもノベルチームにjoinして体験してください!!!

さて今回は2022年にぼちぼち始めたCPANモジュールのメンテナを引き継ぐ活動についてお話しようかなと思います。

CPANモジュール

CPANモジュールとはご存知プログラミング言語Perlのモジュールシステムのことです。

Perlインタプリタに付随しているコアモジュールも含めて、PerlではCPANと呼ばれるアーカイブにモジュールがアップロードされ、cpanmやcpmなどのツールを通してインストールし利用する世界観になっています。

TeXのモジュールアーカイブのCTANに影響されて作成されたと言われていることからも分かる通り、CPANは1995年から存在しており、歴史的にも古いシステムになっています。

そんなCPANには大小様々なモジュールがアップロードされています。特に有名どころではAcme名前空間でしょうか。 他の言語に無い特徴ですが、PerlのモジュールではAcme::と名前がつくモジュールはジョークモジュールとなっていて、様々なおもしろモジュールがアップロードされています。(どういう物があるか知りたい方はAcme大全がオススメです)

CPANモジュールの今

そんなCPANモジュールですが、Perl使用者の人口減に伴って、新規モジュール開発及びモジュールのメンテナが減少傾向にあります。

最近ではElasticsearchの公式クライアントライブラリのSearch::ElasticsearchもElasticsearch8を持ってPerlクライアントの提供を終了することを発表したりしています。

日本でもPerlを書かれていたエンジニアの方々が、別の言語にコミットすることになったり、また多忙でPerlを書く時間が取れなかったりと、様々な理由でメンテナが減少しています。 使わないモジュールのメンテナンスをし続けるのはなかなかしんどいですよね。

Perlではここ数年@INCがカレントディレクトリから削除されたことなどもあるため、継続してメンテナンスをしていくのは後方互換性が強いPerlといえども必要そうです。

とはいえ、はてな社にはまだPerlで元気に動いているPerlプロダクトがありますし、何よりid:anatofuzはPerlが好きなので、できればモジュールのメンテは継続していきたいです。

他にはCPANモジュールではないですが、Perlの公式Dockerイメージの管理もごく数人で行っているので、こういったところにもコミットしたいなと思っていました。

CPANモジュールのメンテに関わる活動

そこで去年はパッチを当てたいOSSを中心にメンテナを引き継ぐ活動をしました。 そこまで件数が多いわけではなかったですが、声を書けながらメンテ権を頂いています。

溜まっていたPRの解決や、新規PRのレビュー等に参加することで、継続してメンテナンスを行っています。

github.com

直近ではTest::WWW::Stubのメンテに関わりました。

metacpan.org

モジュール以外ではdocker-perlやOpenAPIのスキーマからクライアントコードを自動生成するOpenAPI GeneratorのPerlクライアントもPRを送っています。

github.com

github.com

CIの修正なども

他にはPerlモジュールは、日本でよく使われるCPANモジュールオーケストレーションツールのMinillaが標準でTravis CI用の設定ファイルを出力していたことから、Travis CIでCIを回しているものが多かったです。

しかしTravis CIは近年では動かなかったりするので、これをGitHub actionsに移動するなどの活動もメンテ権をもらうついでにシュッと進めています。

github.com

CPANモジュールのメンテを引き継ぐ方法

CPANモジュールのメンテはGitHub等のリポジトリを引き継ぐ + CPANモジュールのcomaintに登録してもらうことで引き継ぐことができます。

gfx.hatenadiary.org

この部分はオリジナルの作者の方にやっていただく必要があるため、コミュニケーションが必要です。 権限を付与されてからは自分のCPANモジュールをメンテするように操作することが可能です。

ただし引き継がれたCPANモジュールをアップロードする際はx_authorityという権限に気をつける必要があります。

blog.64p.org

※追記 id:shoichikaji さんより最近はいらないとの情報を得ました!

※追記ここまで

新しいモジュールを作りつつメンテもしていく

新しいモジュールを作るのも楽しいですが、既存のモジュールのメンテをするのも盆栽をするようで楽しいです。 また偉大な先人のコードに自分も関わることができ、広く使われていく体験もできるので、ぜひPerlに興味がある方はCPANモジュールなどに関わっていきましょう!!!

明日のはてなエンジニアアドベントカレンダーは同じチームのid:deflis55さんです! お楽しみに!

zshでPATHが壊れないようにPATHに新しいディレクトリを通す

zsh

TL;DR

特に順番は気にしないとき

path+=('/hoo/bar/baz');

最初にいれたいとき

path=('/hoo/bar/baz' $path)

PATH通そうとして壊れるヤツ

UNIXを使っている上で避けて通れないのが環境変数$PATHでしょう。 :区切りにディレクトリを列挙して、列挙されているディレクトリ直下に置かれているバイナリファイルをコマンドとして使えるようにするアレですね。

そんな$PATHに新しいディレクトリを追加しようとして、ついつい次のような事故がよく置きます。

export PATH="/hoo/bar/baz"

こうしてしまうと最初から$PATHに設定していたデータが吹っ飛んで、PATHの中身が/hoo/bar/bazだけになってしまいます。こうなるとlsとかのコマンドが使えなくなる訳ですね。

zshだと$pathで配列として扱える

この問題は何が原因かというと$PATHの中身が単なる文字列なのが結構原因何じゃないかなと思っています。 $PATHは明らかに配列構造なので、配列のインターフェースとして扱えればある程度事故が減るはずです。

zshではなんと$pathという変数があり、機能そのものは$PATHと同様に環境変数PATHなのですが、$pathは配列として設定されています。

これによってzshでは配列に対して+=で末尾に要素を追加できるので、path+=('/bar/baz')とか書いておけば、export PATH="$PATH:/bar/baz"と書いたのと同じ意味になります。最後にPATH書く必要がなくて便利。

とはいえ先頭についかするunshift相当の操作は演算子でできないので、path=('/hoo/bar/baz' $path)みたいに書く必要があります。まぁこれはしょうがない。

という訳でzshでPATHを操作するときは$path使ったほうが便利です。どうぞお試しください。

参考

stackoverflow.com

git.ioは非推奨(read only)になってしまったので注意する必要がありそう

Perl

表題が全てシリーズです。(シリーズとは)

完全にノーマークだったのですが、GitHubが提供していた短縮URLサービスのgit.ioが4月27日を持ってread onlyに移行しています。

2022-04-27 Update: While the git.io url redirection service is read-only and use of the service is limited, we have received feedback from developers and academic researchers who have published git.io links in print documentation and research papers. In order to preserve the integrity of these historical documents, we have decided to archive the current git.io links in a new read-only service that will allow us to serve redirects for those links longer term.

As we continue our analysis, we may remove individual links that point to spammy, malicious or 404 links. Our goal is to not break links relied on for legitimate use, especially by the academic community, while preserving the security of developers on GitHub.

That said, we still encourage users to make use of one of the many URL shortening services available with greater functionality than the git.io service provided. GitHub support will not be able to update or edit redirection records served by the git.io archive service.

github.blog

もともとは4月29日に全てのリダイレクトを止める方針だったようですが、論文等ですでに利用されていることもあり、リダイレクトは止めず、新たに追加/編集等ができない読み取り専用に移行したようです。

(これはgit.ioがスパムなどの目的で使われてしまっており、そのメンテナンスコストを鑑みての判断らしいです。)

read-onlyになったのでまだ使用できるとはいえ、非推奨になってしまったので、新たなURLに移行するのが良さそうです。

Perlの人むけ情報

Perlの人向け情報としては、cpmをcpmを使ってインストールする方法が、以前はgit.ioを使ってインストールする方法が推奨されており、この問題で推奨インストール先のURLが変更されているので注意が必要です。

github.com

これは作者のid:shoichikajiさんからもCHANGELOGで変更が呼びかけられています。

github.com

差分は次のような感じです。

旧版

$curl -fsSL https://git.io/cpm | perl - install -g --with-develop --with-recommends --show-build-log-on-failure

移行版

$curl -fsSL https://raw.githubusercontent.com/skaji/cpm/main/cpm | perl - install -g --with-develop --with-recommends --show-build-log-on-failure

ということで気づきベースで変更していくのが良さそうです。git.ioがこんな状況になってたの知らなかった....。

5.32以降のdocker-perlでのcpanmは`https://www.cpan.org`に繋ぎに行くようになります

2022/06/13 追記

一旦この修正はrevertされたので、現在はhttpsで繋ぎにいかなくなっています

2022/06/03 23:46追記

skajiさんの指摘でPERL_CPANM_OPTを指定した状態だと、cpanmの一部の挙動に制限がかかることがPRに書かれました。 この状態だとmetacpanやcpanmetadbのresolverが使用できなくなるので、今後変更があるかもしれません。

github.com

追記ここまで

表題がすべてですが、 library/perl: Update for cpanm update and HTTPS install by default by zakame · Pull Request #12569 · docker-library/official-images · GitHub　のPRがmergeされ次第、5.32以降のdocker-perlでのcpanmはhttps://www.cpan.orgに繋ぎに行くようになります。

これは先日docker-perlでインストールされるcpanmのバージョンを最新にしたところ、docker-perlのメンテナのzakameさんが以前のCPAN脆弱性対応のために乗り気で入れたものです。

具体的に何をしたかというと、環境変数としてPERL_CPANM_OPTに"--from https://www.cpan.org"を設定しています。 これはcpanmがデフォルトで接続に行く先をhttps://www.cpan.orgにする設定です。

この変更によって表題のことが行われます。

影響のあるPerlバージョン

5.32以降の安定バージョンです。 正確に言うと5.32.1, 5.34.1, 5.36.0の3バージョンが影響を受けます。　 docker-perlのtagの関係上、5.32と指定した場合は5.32.1と同じ意味になりますので、5.32以降のPerlをdocker-perlで使っている方は影響があります。

https://hub.docker.com/_/perl

対して5.30以前のPerl Imageは影響を受けません。 これはdocker-perlの現在の開発方針が、「EOLを迎えていないPerlバージョンのみImageの積極的に更新を行う」方針であるためです。

endoflife.date

(そのため現在でもDebian11(bullseye)ベースのイメージは5.30以前のPerlバージョンはなかったりします。)

以下にこの変更による影響をまとめます。

DockerImage自体

ca-certificatesとcurlがslimのImageでもインストールされたままになります。

github.com

cpanm

cpanmのバージョンが最新になります。

特に問題なくcpanmでモジュールインストールが可能です。 テストではMojoliciousをインストールしています。

github.com

ciの結果を見る限りしっかりhttpsでインストールされてます。

carton

Cartonに関しては環境変数が別となるのでhttpのままになります。

github.com

いやでもhttpsで接続したいんだが...!? という方はCartonの後継プロジェクトとなっているCarmelの方をお使いください。 CarmelはCartonと同じ機能を持ちながら、デフォルトでhttps://cpan.metacpan.org/に繋ぎに行くので安心です。

github.com

cpm

特に影響はないと思われます。

まとめ

  • 5.32以降のdocker-perlでのcpanmはhttps://www.cpan.orgに繋ぎに行くようになります
  • 同時にcpanmも最新になります
  • docker-perlはEOLを迎えてないPerlのバージョンのみ面倒を見ているので、docker-perlを使う方はバージョンに注意しましょう

現場からは以上です