株式会社はてなに入社しました
YAPC::Kyotoの思い出 #yapcjapan
こんにちは。そろそろ京都に引っ越して3年のid:anatofuzです。
先日のYAPC::Kyotoではスタッフをしていました
コアスタッフではあるものの、昨年末から今年にかけて引っ越しがあったり、本業の仕事もなかなか大変で平日は仕事をしてそれ以外のことができない、土日は疲労という感じで身動きが取れない、様々なことが発生してメンタルも死*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を学生支援スポンサーメインのスポンサーとして協力させていただきました。
学生旅費支援制度、勝手に裏話すると、今回は実はスポンサーのリストに載ってないけど @AnaTofuZ も拠出してるんだよね。みんなのカンパでPerlConに行ったあなぐらが、次は学生みんなの支援をする、というのマジで良いサイクルじゃないですか?みんなもっとあなぐらを褒めてあげて! #yapcjapan
— 技術王者papix (ChatGPT評) (@__papix__) 2023年3月21日
会社という訳ではないので金額等柔軟に対応していただいたid:papixさんには感謝です。*3
個人的にはスポンサーして無事学生さんの旅費を支援できて満足という感じだったのですが、忘れていたスポンサーチケットを、ちょうど学生チケットの購入を逃してしまった学生さんにお譲りすることができることなどがあり、そういう意味でも今までコミュニティからもらえた恩を少し返せたかなとは思っています。
あとは沖縄から学科の後輩のid:e205723とid:mattari_matayuをYAPC::Kyotoに呼べたのが良かったかなと思っています。沖縄のPerlコミュニティにお世話になったので、沖縄の人々にもどうにかしておきたかった。
次回はYAPC::Hiroshimaになりそうな気配がありますが、個人的に地元の山梨でYAPCをやるまではやっていくぞという感じでもあり、今回あまりコミットできなかった分次はやっていきたいので、次回は広島でまたお会いしましょう。よろしくお願いします。
PerlにおけるGraphQLライブラリのまとめ
リッチなフロントエンドを開発していると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でスマートに配列からランダムで特定個数の値を取得する
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の)モジュールのメンテナを引き継ぐ活動を始めた件
これははてなエンジニアアドベントカレンダー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を中心にメンテナを引き継ぐ活動をしました。 そこまで件数が多いわけではなかったですが、声を書けながらメンテ権を頂いています。
@cho45 こんにちは! はてなでPerl書いているAnaTofuZです。いくつか社内でcho45さんが作成された/メンテナンスされているCPANモジュールを利用させていただいているのでメンテに加わりたいです。社内にも他にメンテしたい方がいるので、まずは自分にメンテ権限いただきたいので相談させてください!
— 八雲アナグラ (@AnaTofuZ) 2022年6月9日
溜まっていたPRの解決や、新規PRのレビュー等に参加することで、継続してメンテナンスを行っています。
直近ではTest::WWW::Stubのメンテに関わりました。
モジュール以外ではdocker-perlやOpenAPIのスキーマからクライアントコードを自動生成するOpenAPI GeneratorのPerlクライアントもPRを送っています。
CIの修正なども
他にはPerlモジュールは、日本でよく使われるCPANモジュールオーケストレーションツールのMinillaが標準でTravis CI用の設定ファイルを出力していたことから、Travis CIでCIを回しているものが多かったです。
しかしTravis CIは近年では動かなかったりするので、これをGitHub actionsに移動するなどの活動もメンテ権をもらうついでにシュッと進めています。
CPANモジュールのメンテを引き継ぐ方法
CPANモジュールのメンテはGitHub等のリポジトリを引き継ぐ + CPANモジュールのcomaintに登録してもらうことで引き継ぐことができます。
この部分はオリジナルの作者の方にやっていただく必要があるため、コミュニケーションが必要です。 権限を付与されてからは自分のCPANモジュールをメンテするように操作することが可能です。
ただし引き継がれたCPANモジュールをアップロードする際はx_authority
という権限に気をつける必要があります。
※追記 id:shoichikaji さんより最近はいらないとの情報を得ました!
メンテありがとうございます!
— Shoichi Kaji (@shoichikaji) 2023年1月11日
ところで、x_authorityに関しては、もうPAUSEが勝手にやってくれるので設定しなくてもOKだと思います。https://t.co/uG4anMFjZl
※追記ここまで
新しいモジュールを作りつつメンテもしていく
新しいモジュールを作るのも楽しいですが、既存のモジュールのメンテをするのも盆栽をするようで楽しいです。 また偉大な先人のコードに自分も関わることができ、広く使われていく体験もできるので、ぜひPerlに興味がある方はCPANモジュールなどに関わっていきましょう!!!
明日のはてなエンジニアアドベントカレンダーは同じチームのid:deflis55さんです! お楽しみに!
zshでPATHが壊れないようにPATHに新しいディレクトリを通す
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
使ったほうが便利です。どうぞお試しください。
参考
git.ioは非推奨(read only)になってしまったので注意する必要がありそう
表題が全てシリーズです。(シリーズとは)
完全にノーマークだったのですが、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.
もともとは4月29日に全てのリダイレクトを止める方針だったようですが、論文等ですでに利用されていることもあり、リダイレクトは止めず、新たに追加/編集等ができない読み取り専用に移行したようです。
(これはgit.ioがスパムなどの目的で使われてしまっており、そのメンテナンスコストを鑑みての判断らしいです。)
read-onlyになったのでまだ使用できるとはいえ、非推奨になってしまったので、新たなURLに移行するのが良さそうです。
Perlの人むけ情報
Perlの人向け情報としては、cpm
をcpm
を使ってインストールする方法が、以前はgit.io
を使ってインストールする方法が推奨されており、この問題で推奨インストール先のURLが変更されているので注意が必要です。
これは作者のid:shoichikajiさんからもCHANGELOGで変更が呼びかけられています。
差分は次のような感じです。
旧版
$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
がこんな状況になってたの知らなかった....。