オープニングと自己紹介
お久しぶりです。なんか前あったのって、Go カンファレンスの時に出展とかされてましたよね?
そうですね。会社で出展をしていて、それのブーススタッフとして参加していたのが前回ですね。
そうですね。あの時は思いがけずお話できて、まあちょっとの間でしたけど。
ブース出展、なんか楽しいけど大変ですよね。じゃないですか。
そうですね。前回、確か2daysだったので、立ちっぱなし2日間で結構大変だったですね。楽しかったですけどね。
いや、2daysとかね、連日になるとマジで大変だよね。本当に。
僕も最近、ブースに立つ仕事があって、1日立ち仕事があったんだけど、まあなんとかなったのと。
去年足骨折したんで、足首。なんか大丈夫かなって思ってたけど、大丈夫でなんとかなりました。
なんか去年大変そうでしたね。
大変っていろいろありましたね。よくわかんない1年でした。
でも出展とか、だからあんまりやったことない人に、結構ちゃんと終わった後サロンパス張るとか、風呂で足を揉むとかしないと翌日マジ死ぬよみたいな話をしたりしていました。
わかります。
僕もね、マカレルやってた時はね、出展ちょいちょい行ってたんで、立ち仕事の人本当すごいなーって思える機会だなって思ってました。
はい、まあそんな感じで、この番組は趣味でOSSをやっているものだという番組でOSSサッカーのソムーがゲストを交えながら、趣味や仕事について話をするポッドキャストです。
ということで、今日のゲストはルフィアさん、カドタさんです。よろしくお願いします。
よろしくお願いします。
じゃあカドタさん、自己紹介をお願いします。
はい、カドタと言います。あんまりこういう場では音声で話すことは滅多にないので、多分初めましての人も多いと思うんですけど、
インターネットだと主にルフィアっていうIDで活動しています。
現Xでは取れなかったので、ここだけ確かプランラインユーザーっていうIDでインターネットに存在しています。
現在、ハテナっていう会社ですね、のアプリケーションエンジニアとして京都で働いています。よろしくお願いします。
はい、よろしくお願いします。そうですね、はい。なので僕は、なんか多分カドタさんとかルフィアさんとか、統一されてない感じで呼ぶことになると思うんですけど、
カドタさんとは、そうです、僕が2019年ぐらいにハテナ辞める直前ぐらいに入ってきて、ちょっとだけ被ってるチームも一緒だったっていう感じですよね。
半年ぐらいですかね。
そうですね。なんか入ってきてくださってたんですが、そうですね、あんまり長くは一緒に働けなかったという感じでしたね。
でも短かったですけど、結構濃密な時間ではありまして。
そうですね。僕としても、いろいろ影響を受けた部分もあるし、面白かったなというふうには思っています。
なので、最近というかたまにネット上でちょいちょい絡むこともあって、嬉しく思っております。
Plan 9のlsコマンドとUnix哲学
今回というのもちょっとお誘いしたきっかけというか、もう久しぶりに僕がツイッターに対して反応してくださって、それについて久しぶりだし、お呼びするかみたいになりました。
びっくりしました。
カドッタさんはその名前の通りプランナインユーザーなので、プランナインの話とか聞ければいいかなと思ってるんですけど、ちょっといろいろ別の話もしていこうと思うんですけど。
もともと僕がツイートした内容としては、ユニックスという考え方っていう、いろんな人がいい本だっていう本で、僕もいい本だと思ってるんですけど、
この本、過激だし原理主義的なところもあるから、そこも含めてネタ半分面白がって読むみたいなのが正しいと思ってるんですけど、やっぱりLSコマンドを結構初っ端に批判してるところが僕は結構好きで、
シンプル・イズ・ビューティフルっていう言葉の解説なんだけど、その中でLSを解説してるのがすごい好きなんですよね。道を踏み外したユニックスアプリケーションの例としてLSコマンドを上げようって、さっき本を読み返して引用したんですけど、つまりLSはもう道を踏み外してるっていうふうに書いてあって。
なんでかっていうと、これもその本にそのまま書いてるんですけど、整列機能はフォーマットの機能を持つ他のコマンドに任せるべきなのだって書いてあって、つまりLSコマンドって単に行試行で1行に1ファイル出せばいいのに、ターミナルに繋がってるときはちゃんとターミナル幅とかをちゃんと見てくれて、マルチカラム出力みたいなのをしてくれるんだけど、
そういうのはマジで余計な機能だから、そんなのはいらんのじゃんみたいなことがユニックスという考え方に書いてあると。この話結構原理主義的で面白いなってちょいちょい言ってるんですけど、そういったことをツイートしてたら、いやいや、プランラインはそうなってますよみたいなことを突っ込んでくださったんですよね。
これちょっとお話ししてもらっていいですか。
これは本当にプランラインでは、LSコマンドを実行すると1行に1ファイル名が出てくるんですよね。
この辺はおそらく文献によるとそうなんだろうぐらいの確像しかないんですけど、オリジナルのユニックスはもともとそうだったと思うんですね。
ベルケンが作っていたユニックスは多分もともと1行1ファイル。多分DSDかなんかで追加された機能なんじゃないかなと思ってるんですけど、マルチカラの機能はプランラインのLSには入っていないし、
LSのLオプションをつけると一番最初にトータルって出ると思うんですけど、あれも入ってないんです。本当にリストが出るだけ。
マルチカラムにしようってなったときにどうするのかっていうと、MC多分マルチカラムの省略形なんだと思うんですが、
MCっていうコマンドが別にあって、それにパイプすることでMCコマンドが適切な幅を計算していい具合にやってくれるっていうのがプランラインの実装ですね。
さすがに毎回パイプするのはめんどくさいだろうっていうので、リストリズカラムかな、LCってコマンドがあって、普段はユーザーとしてはこれを使うほうが便利ではありますね。
でもそのLCも別にやってることとしては、
やってることとしては、LSパイプ、MC、本当にそれだけのコマンドです。
そうですね、プランラインのシェルスクリプトにそう書いてあるやつが書いてあるだけっていう感じなんですよね。
これはさすがプランラインだなっていうふうに思いました。
どういうことですか。
いやいや、なんかちゃんと、ちゃんとしてる、ちゃんとしてる?
でもなんかこういう、僕がもともと思ってた文脈としては、結構小さいものを組み合わせて、もっとレバレッジを効かせていきましょうみたいなことってよく言われると思うし、
Goのインターフェースなり、何なりでも最小のインターフェースをコンポジションすることで複雑なことをできるようにしましょうみたいな、そういう感じだと思うんですけど、
さすがに人間側としては、そこは三つ結合であってくれよみたいなのがあるわけじゃないですか。
ちゃんとLSで、別にマルチカラムにしてくれてもいいじゃんみたいな、そこでいちいちパイプかますのは認知負荷が高いよねとか、
直行したものを組み合わせると、いろんな可能性があるのはわかるんだけど可能性がある分、組み合わせ爆発しちゃうから、
人間にはちょっと負荷が高いから、人間にとってはもうちょっとわかりやすく、大きいパッケージにしておいたほうがわかりやすいよねっていうふうに思う部分もあるわけですよ。
でも、最近思うのは、AIってやつにとっては、そういう人間とは全然違う認知能力を持ってるので、
AIに対してまたそういうシンプルなプログラムをたくさん渡してやるほうがいいんじゃないかなっていうのを最近結構思い始めていて、
そういうAIのために、AIって決定的な動きをするから決定的な動きをどう与えるかっていうのが大事だと思うんですけど、
やっぱりそういう決定的な動きをする、最近みんなCLI、CLIって言ってるけど、CLI何なりを提供するのって、実はまた大事になってきてるんじゃないかなっていうのを思ったりしてるんですよね。
そうですね。さすがにプランラインでAIエジェントは動かないと思うので、プランラインのツールがそのまま使えるかって言われてもさすがに無理かなとは思うんですけど、
そうですね。そういうシンプルなツールの組み合わせでやりたかったことの一部を補うっていうのは、UNIXらしい思想ではありそうですよね。
なんかプランラインで動くAIエージェントみたいなのってないんですか?それこそGoとかで作ろうと思えば作れそうな雰囲気もないこともないのかなと思うんですけど。
現状は動いてるものは聞いたことがないですが、完全にGoで作られてるなら動く可能性はありますね。
そうだよね。とはいえ、多少考え方のミスマッチも多いところだから、僕の書いてるGoライブラリとかがプランラインに対応してないじゃんっていう指摘を門田さんに受けたこともあるんで、すいませんっていう感じなんですけど。
そうですね。あれは結構OSS活動とかも長い間やってるので、概ね分かってはきてるんですよね。
ライブラリとかツールの作者にプランラインの対応したブルーリックを見てくれってお願いしたとき、最終的には書いた人じゃなくて、メンテナーっていうかオーナーがその面倒をずっと見ていかないといけないっていうのがあるじゃないですか。
そうなったときに、過去にGitの移植とかをしてるときにいろいろ言われたんですけど、プランラインの環境がないからメンテできないっていうのは当然そうだと思うんですよね。
例えばメイクファイルじゃなくて、プランラインのメイクっていうのはMKっていうまた別のツールなんですよ。一般的なメイクとは違う文法になっていたりとか、コマンドがあったりなかったり、ハインドとかもないんですよね。
あれも便利なんですけど、UNIXらしくないのでなかったりするんですよね。そういう差分がある中で作ったからじゃあメンテしてくれって言っても、普通は難しいって返ってくるのが当然。
中には優しい方とかがいて、壊れるかもしれないけどそれでいいならって言ってくれる人はいるんですけど、今後ずっとメンテしてくださいっていう話になるので、分かるんですよ。難しいからフォークしてくださいって言われたら理解はする。
なので、前回対応して、なんて言ったんでしたっけ、そんな詰めてるつもりはなかったんですか。
あ、そんな詰めてるつもりでは、詰められたわけではないけど、そういう、そうだねみたいな話を。Goはね、ちゃんと結構珍しく、珍しくっていうか、その辺の経緯の話は後半でするかもしんないけど、ちゃんとプランナイン対応されてる言語なので、結構簡単に壊れてもいいんだったらプランナイン対応を素な形で入れることができるじゃないですか。
なんかインターフェースだけ、インターフェースっていうか関数のシグネチャーだけ揃えておいて、別ファイルにすればいいだけの話なんで、そういったところはね、なんていうか、とりあえず入れてもいいかっていうふうには思いやすい部分ではありますよね。
はい。なので、やっぱ難しいのは維持していく方だよなとは思いますね。
そうだね。どうやって構築するのかもよくわかってないからな。でもやろうと思えば構築できるんだろうなっていう環境ね、とは思ってるんですけど。
昔は、それこそパールとかだと、ソラリス対応みたいなのが入ってることが多くて、求められることが多くて、でもソラリスなんてもうね、商用OSだからないしみたいな。
そういうので、それは困ったことがあったし、よくわかんない分岐でやってるからなんだろうこれみたいな、もう無視でいいかみたいなのはあったりはしましたね。
手元に環境がないのは難しいですよね。
チーム異動とGoサブ会
最近は本当に、そういう環境をすぐ用意できるかできないかでだいぶ逆にギャップが広がってるっていうか、そこに逆に溝が埋まれちゃってる部分はあるかもしれないですね。
昔はなんか結構、パールとかだと、シーパンテスターズっていう謎の分散テストのボランタリーな仕組みがあって、みんなが自分のマシンとかでテストを動かしてそのテスト結果を投稿してくるみたいな、なんかそういうのがあったんで。
なのでなんか世界中のいろんな人のいろんなOSからテストレポートが集まってきて、なんかエラーがわかるみたいなのがあったんですけど、今もあんのかな。
それはそれでもちろん捌くのすごい大変なんですけど、昔はそういうすごくないやり方しかなかったけど、最近は普通にコンテナ上で任意のOSやりやすいけど、そこに載ってないやつは逆にやりづらいみたいな感じなのはあるのかなって思いますね。
そうなんですよね。なんか最近ちょっとGoのライブラリでだいぶダーティーなことをやってるやつを作ってたりするんですけど、後で話題に出るかな。やってるんですけど。
その手元に関係はないかつGitHub Actionsにも関係はないってなった時にどうしたらいいんだっていうのは思ったりするんですよ。
例えばDisk5って読むんですかね。あれとか。
はいはいはい。確かにそういうCPUアーキテクチャが違うやつとかだと、マジで困るっていうのはありそう。確かにそうだよな。
その話はちょっとしたいんですけど、ちょっと近況を挟みますか。近況をね。なんか最近移動したんですか。
移動しました。もともと、あれいつだったかな。2018年の12月ぐらいに原作のハテナに入社して、そこからずっとアカレルだったので、もう6年ぐらいアカレルの社歴にやってるんですが、
全く不満がなかったんですけど、そろそろ移動どうですかって話があって。6年やってるしいいかなって思って、今は漫画メディアの移動しました。
そうだよね。ハテナ社は結構長く同じチームにいると結構ローテーションするみたいなところもあるから、そういう意味では6年とかは長いよね。
長いですね。ただ最近は、以前はあんまりわからないんですけど、最近はそんなに移動の頻度が高いっていうわけでもないみたいですけどね。
確かにそうかもしれないね。結構ビジネス的にも大事なことやってたりすると、Cマン的な人は抜けづらいみたいなのはありそうだもんな。
そうですね。ただ移動してみて思ったのは、もう社内転職みたいな感じだとは思いました。
ほう。それは結構環境が違うっていうことですか?
はい。結構違いますね。たぶんいつかはわからないんですけど、パールのアプリケーションを書いてたときは、話を聞くとどこに行っても大体一緒の環境だったみたいなんですよね。
使ってるフレームワークとか、どのファイルをどこに置くとか、そういうのが結構統一されていて、移動してもそんなに困らなかったって話をよく聞くんですけど、
今はもう使ってる言語も違うし、フレームワークも違いますし、物によってはEC2環境で動いていたりとか、物によってはコンテナ化していたりとかあるので、
結構使ってるツールのキャッチアップっていうのはコストがかかってますね、今。
まあそうだよね、きっと。やっぱりそれこそパレルも漫画もかなり今の果てなんでも歴史のあるサービスになってきてるから、
それより前って多分今残ってるプラットフォーム的な、ブログはちょっとまた違うけどブログブックマークみたいな、そういう結構パールで書かれたものが多くて、
その後出てきた、そうだよね、パレルとか漫画とかは、それはそれで別の分岐の歴史があるから、文化の違いはありそうって感じはしますね。
でも漫画は、もともと結構パールとか、バニラ・ジェイスとかがすごい、まあまあ大昔だけど起点だったと思うんですけど、今はGOも使ってるんですか。
GOを使えるっていうことで移動したと書かれてますけど。
まあそうですね、今現時点で使ってるかっていうと、使おうとしているが多分正しいですね。
基本的には全然パールのアプリケーションが、現状は主流です。
すごい、もう日本のね、web、漫画を支える大サービスが。
まあでもなんかまた全然違う、そのシステム的な難しさもありそうですよね。
そうですね、難しい、そうですね。
なんかこれ面白いなって思ったのなんかありますか、ツールなりアーキテクチャなり、仕組みとかでも。
どこまで言っていいのかわからないので、ちょっとこれは後で確認させてほしいんですけど。
面白いなと思ったのは、今後RとGOのアプリケーションが並列で動くことになるんですよ。
一気に移行するのは不可能なので、ちょっとずつ移行していこうとしてるんですね。
この時にGraphQLのエンドポイントが一個あって、
GraphQLをどうやって分割するのかっていうところで、GraphQLフェデレーションっていう仕組みを導入してるんですよ。
そのフェデレーションの仕組みが結構、
GraphQLってもっと分割できないものだと思っていたので、
そういうやり方があるんだっていうのが結構面白かったですね。
なるほど、なるほど、確かにな。
なんかそういうの、その話は多分どっかでされてる気がするから問題ない話な気がする。
その多分、段階的移行の話とフェデレーションの話は多分かてなGOかなんかで話されてた気がしますね。
じゃあ大丈夫ですね。見慣れたんですね。ありがとうございます。
はい、内容はリアルタイムじゃないこともあれどチェックはしております。
なので、そうですよね。それこそここにも話題で書いてくださってますけど、
GOサブ会とかも今やられてるっていう感じなんですよね。
これはどういう活動なんですか。
はい、はてなの中で各チームが個別っていうのかな。
チームごとでいろんな技術を採用してるんですよね。結構独立性があって。
GOを採用してるチームもあれば、Node.jsのバックエンドを採用してるチームもあるっていう状況で、当然パールもありますね。
そのチームの中で閉じてるんではなくて、もうちょっと横断的に技術的な共有をしましょうみたいなのが、
サブ会として結構いろんなものがあるんですよ。
ラクラ会とかがパールで、フロントエンド会とかセキュリティ会とか、
そういう業務時間内で大体このぐらい時間使っていいですよっていう枠の中で、
情報共有とかそういう活動をするための仕組みをサブ会って呼んでるんですけど、
それのGOの話をするための会を今やってます。
それに参加してるっていう感じですね。
その話多分前ステニアンがどっかで発表してたの見てたけど、
割とはてなGOを書いてる人はいるけど、あんまり知見が共有されてないよねみたいなことが書かれてて、
僕もなんとなく当時の当事者的な意識を感じてしまって、うう、みたいな気持ちになりました。
それこそCTOのモテメンさんとか僕とか結構、なんかOSSとか書いてはいるけど、
社内がおろそがになってたんじゃないかみたいな、そういう感じがありました。
でもモテメンさんとかも結構いろいろ記事書かれたりとか登壇されてたりとかしたので、
社内の還元はどうかはわからないですけど、
コミュニティ内向けの還元は結構良かったんじゃないかと、外から見て思いますけどね。
そうですね。モテメンさんは本当そうだと思います。
なんかはてな、GOやってるんだっていう、そういう雰囲気が出るだけでも全然違いますからね。
まあで、そっか。
GOサブ会何人ぐらいでやってるんですか?
うーん、今は7から10ぐらいが参加して、
実際、週に30分集まって話をする時間に参加してくれているのはだいたい7から10人ぐらいが平均で、
スラックのチャンネルもあるんですけど、スラックのチャンネルに入ってきてくれている人はそれなりにいますね。
ちょっとさすがに数えてないですけど、何十人ぐらいかな。
まあそうだよね。普通にGOをなんだかんだで関わったりしてる人は多いだろうから。
でもその週次の定例的なやつが10人弱ぐらいだったら、サイズとしてはちょうどいい感じがするね。
あんまり多くても、話せなくてそのまま終わるみたいなこともなりますしね。
そうだよね。でもなんかさ、そういうサブ会みたいなのをやってると、
どんどんやっぱり少人数で議論してるとどんどん話がマニアックになっていくというか、
レベルが上がりすぎちゃったりとか、なんかそういう社内の実情と乖離していくみたいなこととかって起きたりしないんですか?
もともとは裾野を広げようみたいな方に視点は向いてた時期があるんですよ。
なんか新しくGOを書く人のために、そういう人たちが参考にしやすい話題をなるべく選ぼうとしてた時期はあるんですけど、
現状だとどちらかというともう書ける人が集まってくれる方の傾向が強いっていうのが最近なんですよね。
そうだよね。きっとそうなるんじゃないかなと思う。
はい。なのでもうその辺は割り切ってしまっていて、
意図して難しいマニアックな話をしているっていうことはないんですけど、
結果的にそうなっても参加してる人からすると楽しんでもらえるかなとは思ってやってます。
でもちゃんとそうか。サマリーをアウトプットしたりとか、そういうのはやってるっていう感じなんですかね。
ちゃんと前者向け、前者っていうか他のエンジニア向けにも最近こんなことやってますみたいな。
議事録とかですかね。そんなに多くないですけど、議事録を見て反応してくれてる人とかは数名ぐらいいますね。
そういうの大事、大事だよね。
なんかGOに関して、この話題メモにも書いてくれてるけど、やっぱりその捉え方みたいなのが人それぞれだから、
どういうふうに社内の標準的な書き方とかを揃えたり、あんまり抵抗感なく接してもらえるようにするとか、
最大公約数的な書き方みたいなのを競技していくみたいなの、結構難しいんじゃないかなって思うんですけど、
そのあたりはどう思ってるんですか。
これは個人の意見なので、作家の総意ではないんですけど、
統一するのは結構現状難しいなとは思ってるんですよね。
他の人から話を聞くと、パールとかだとどのファイルをどこに置くっていうのが決まったりとか、
データベースアクセスはフレームワークを使うとか、ある程度決まってたらしいんですけど、
現状の社内のGOのソースコードとかを見ると、結構まちまちなんですよね。
当然最初は統合されたものから出発しているわけではないですし、
あとちょうどコロナとかもあって、あんまりリアルで話すっていうのも少なくなった時期を挟んでいるので、
結構独立性が強くて、今ある動いているものに対して、
こうしてくださいっていう強い根拠がないなっていうのが今思っていることですね。
なので、統一した書き方にするとか、統一したフレームワークにするとかではなくて、
うまくいけばGOの良しとしている思想とか、こういう文化なんですよとか、
そういうのをうまく共有するほうがうまくいくのかなとは思います。
うんうんうん、確かに。そうですよね。やっぱ結局チームで協議して決めれば良いみたいなところはあると思うので、
外しちゃいけないところっていうか、外してほしくないところみたいなのはあるけど、
チームのスキルマップみたいなのを作る時も、結構ちゃんとチームごとに作ったほうがいいみたいなのは言われてるから、
それを全社共通のスキルマップにしてみたいにすると、もう項目が膨大すぎて無理ってなっちゃうから、
このチームではこうやっていきましょうみたいな、そういうのがいいんですかね。
Goの野暮ったさとエラーハンドリング
はい、いつ頃でしたっけ、ソンムールさんもGOは野暮ったいのがいいみたいな資料を出してたと思うんですけど、
あれはすごくいい資料だと思うんですよね。
考え方を取り入れるとか、こういう思想なんだっていうのを伝える意味ではすごくいい資料だと個人的には思ってます。
ありがとうございます。これ結構いい資料ですよね。我ながらいい資料だなと。
いい資料ですよ、これ。長かった記憶がありますけど。
そうですね、120枚ぐらいありますね。
多分このエピソードでも、このポッドキャストでも何度か話してるんですけど、
KHローデックってやつを使ってこのスライドを生成したんですけど、最初生成がそんな早くなかったので、生成に15分ぐらいかかって、
これは無理だなってなって、すごい高速化をしました。高速化するきっかけになったんですけど。
そういう意味でチームでどういうふうにしていくかっていうのと、
あとそうそう、この資料でも話したけど、今では僕はもう忘れてたんだけど、
大体の多くの、オブジェクト思考言語って規定クラスみたいなのがあって、全部ツリー構造になっててみたいな、
そういうオブジェクトツリーみたいなのがあるけど、語ってそういえばそれないんだよなっていう、
ストラクトがバラバラの場所にあって、インターフェースがいろんなところにあるから、
わりとそういう、ネームスペースもフラットに近いし、あとネームスペースとインターフェースみたいなのが直行してる、
初結合なんですよね、この階層の下にインターフェースがあってみたいな、そういう感じになってないから、
それってすごい強力なんだけど、やっぱり最初話してたようにすごく複雑で分かりづらさを持ち込むところもあるよなっていうのは思ってはいますね。
そうなんですよね、なんか明記されている方が何を実装しているかが分かりやすいっていう意見もあるし、
リーダーライターみたいなところに形さえ合ってれば通る方が使い回しがしやすいみたいな話もあって、
この辺はその人の価値観が大きいなと思いますね。
そうだよね、リーダーライターみたいなのがある方がいいじゃんって僕も思うんだけど、価値観だし。
でもそういうのってちゃんと、例えばOSファイルみたいな階層にあるパッケージに強く密結合されててほしいっていうふうに思う人もいるよなっていうのは思いますね。
でも最近はやっぱりここに何か書いてくれてるけど、AIが統一的に書くようにすることが大事っていうのはありますよね。
AIが統一的に書くようにするのは大事?書きましたね。
後よりかは、ごめんなさい、僕が勝手に拡大解釈しただけかな。
なんかAIが書くことが増えてるから、スキルとかをちゃんとするのがいいじゃないかみたいなことを書いてくれてたなっていう感じです。
そうですね。もともと多分この文脈って確か、Goってエラー処理がIfErrorNotEqualNilいっぱい書きますし、
あとパールとかも多分そうだと思うんですけど、動的言語に比べてちょっとテストするためにその仕組みを持ち込まないといけなかったりするじゃないですか。
準備してないとテストできないとかになりがちなんですけど、動的言語だと結構その辺自由に後から差し替えられたりとかして、
そういう自由度がないので考えることが増えて大変っていう意見は何か聞いたことがあるんですよね。
そういう難しさをちょっと緩和しようと思って、ライブラリーとして実装してるものが今あるんですけど、
ただそれはもともと記述量とか考えることを減らそうとした目的なんですが、
最近はAIがだいたい生成したりしますし、その辺もちゃんと指示さえすればハーネスっていうんですかね、
ハーネスとかを整えていればもともとそんな意識しなくてもテスト可能になってきたりするので、
ライブラリーで頑張るっていうよりは、そういう準備をするほうがモダンなのかなっていう気持ちはあるっていう文脈ですね。
なるほど、なるほど。そっかそっか。確かにね。
語って結構意図的に隙間がある言語だなというふうに思っているんですよね。
ライブラリーとライブラリーの間に隙間があって、だからライブラリーの責務が明確っていうか、
こっちのパッケージとこっちのパッケージに似たような処理を作らないみたいなところが結構徹底されてると思ってて、
ただその分その間をつなぐ行動みたいなのを結構腕力で書かないといけないみたいなところがすごくありますよね。
ただそれも確かにAIが、AI単純な腕力あるからやってくれるよねっていう感じはあるよね。
なんか技術量が多くて大変っていうのは減ってくるのかなっていう予感はしますよね。
ただやっぱり本質的じゃない行動が多くて読みづらいみたいなふうに感じる人とかはいるかもしれないし、
そういうのは減らしてったほうがやっぱり良いのかなとは思うけど、
エラー処理が別にそんな情緒だとは慣れてくると、良くも悪くも思わなくなるみたいなのはありますよね。
それは慣れてるからだと思いますよ。
まあ確かにね。本当はやっぱり言語としては正常フローみたいなのが見やすくなってて、読みやすくなってて欲しくて、
補足的にエラー処理が読めるみたいになってる方がいいっていうか、まあいろいろ考え方はあると思うんですけど。
でもプログラムってだいたい真面目に書くと、エラー処理が大半みたいになっちゃうから、
ちゃんと読むとあれメインのロジックどこなんだろうみたいになることはあるよね。
lufia/plugとlufia/tryの紹介
はい、まあでも個人的にも明記されてる方がわかりやすいって思ってるタイプなんですね。
でもまあなんか去年いくつか面白いOSSを書いてて、両方一応僕は作ってるなっていうのは見ていました。
プラグってやつとトライってやつですね。これはどういうものなんですか?
さっきの話のとおりでして、プラグっていうのはテスト用の差し替えライブラリですね。
もともとはてんてんさんがテストタイムっていう時間をtime.nowを置き換えるライブラリを作ってたんですけど、
そこの裏側で使っている仕組みとしてオーバーレイっていうのがあるんですよ。
なんか黒魔術っていう紹介をよくされるんですけど、事前にこのファイルをこれに置き換えるっていうルールをJSONで書いておくと、
実際にビルドをするときに本当にそのファイルが置き換えられて、ビルドして結果が出てくるっていうものなんですよね。
これを使ってそのテストタイムを何をやってるかっていうと、標準のソースコードのtimeっていうパッケージの中のnowが入ってるやつを置き換えてるんですよね。
そうすると、Mock可能なtime.nowができるので、これでMockをすることによって時間を固定してテストができるっていう
なんかすごい激しいライブラリなんですけど、それを見たときに面白いなって思ってしまったんですよね。
面白いなと同時に、さっき動的言語と比べてテストをするために準備をしないといけないっていう課題可能があった時期で、
この置き換えができるんだったら静的解析で置き換えたい部分を全部標準のソースコードから持ってきて書き換えればいいんじゃないって思って、
プラグっていうのを作ってるのがきっかけですね。
使い方とかはGitHubのリポジトリを見てもらえれば書いてあるんですけど、
セットっていう関数を使うと、セットに渡している状態の渡したものを静的解析でばらして、
あとは置き換えてビルドをするっていうことをやるライブラリーです。
そうだよね。もともと、どうぞどうぞ。
していません。もう一個のtryっていうのは、これは激しいですよね。
これ気持ち悪いよね。これは褒め言葉ですけど。
ありがとうございます。分かってます。
これは、エラー処理を何度も書きたくないっていう課題に対しての個人的なアプローチ、やってみた、なんかできたってやつなんですけど、
裏側で、確か時期としては、これを書いたのが、Goの公式のコアチームから発表が、
もうライブラリーのシンタックスは変えませんっていう発表が確か、いつ頃でしたっけ。去年の年末ぐらい。
去年5月?もうちょっと前だっけ。去年の、だから僕の発表には入ってるんだよね。だから、2025年の前半ではあると思う。
もう1年ぐらい経ちそうなんですね。
それを受けて、公式に対応されないならやってみようかなって思ったんですよね。
これ何やってるかっていうと、ハンドルっていう関数を用意しておいて、それが呼ばれたときに、スタックにあるスタックのポインタを覚えておいて、
エラーが発生したときに、スタックを戻すっていうことをやってるライブラリです。
実際、例外処理がある言語と同じことを知ってるんですけど、ただGoでこれをやろうってするのはあんまりないので、珍しいですね。珍しいライブラリだとは思います。
そうだよね。1個1個それぞれ話すと。
このプラグっていうのは、よくあるそれこそ組み込みのライブラリみたいなやつの挙動をまるっと入れ替えることができるみたいなやつで、
ルビーだとタイムコップとか、それこそNowを差し替えたいみたいなのはいろんな言語にあるんだけど、Goは当然できなくてっていうのがあったんですけど、
でもてんてんさんがやってるから、じゃあそれをもっと汎用化して、いろんな関数を差し替えられるようにしましょうというふうにしたっていうところですよね。
これもね、これもなんか結構僕は逆にてんてんさんにやられたなって思ってた部分があって、僕はフレックスタイムっていうライブラリを作ってて、それもテストのために時間を差し替えるやつなんですけど、ちょいちょい使われてるんですけど、
フレックスタイムってやってることとしては、タイムタイムと同じメソッドなりフィールドを持つ、また別のものを返すようになってるんですよね。
それで一応ドロップインリプレイシスメントはできるようになってるんだけど、ちょっと違うものが返るんだけど、てんてんさんのやつの場合はもう本当にそのまま置き換えてるんで、タイムナウを呼ぶだけで使えるし、同じちゃんとタイムタイムが返ってくるので面白いなって思ってたんですけど、それをさらにプラグだと汎用化してるっていう感じですね。
これはどうなんですか。仕組みとしてはオーバーレイを使ってるから、そんなに壊れることもなさそうって感じなんですか。どうなんですかっていうのと、これは実際使ってるんですか。
そうですね。さすがに公式のソースコードに手を入れてしまうので、本番で動作するものには使わないほうがいいとは思うんですよね。ただ、壊れたりはしないとは思いますね。
自分自身が使ってるのかで言うと、使ってはいます。今、濁したのは今1個のパッケージしか対応できてないんですが、Goってドット3つでそれ以下っていう指定ができたりするじゃないですか。
テストするときもそうしたいんですよね。そうしたいんだけど、オーバーレイが今1パッケージしか対応できてないので、直したいなと思って、まだ手を動かせてない。部分的に使ってはいますし、ちゃんと動いてそう。
なるほどね。オーバーレイ、本番で使うのとかも怖いし、やらないほうがいいので、テストでやる分にはいいでしょうっていうそういう塩梅なので、いいのかなっていうのと。
これはある意味明示的なフラグなので、普通にライブラリのGoGetとかGoInstallとかでは指定はできないから、変なセキュリティ的にやばいものを入れ込まれる心配もないっていうことなのかな。
セキュリティが絶対大丈夫かって言われると、そっちの専門家ではないので、間違ったこと言ってしまうかもしれませんが、たぶん大丈夫だとは思います。
別にそれはどこにどんなリスクがあるかわかんないけど、Goはすごい気をつけてるし、とはいえセキュリティホールがないソフトウェアなんてないのでみたいなのはあるけど、でもそういうサプライチェーンアタック的な時にこれが悪用されることはないようにすごい考えてはいるんだろうなっていうのを思ったっていう感じです。
で、このトライですよね。これはなんかすごいっすねーっていう。これやっぱなんかその、確かにトライっていうから、ある意味トライキャッチ的な帯域ジャンプではあるんだけど、
これちょっと気持ち悪いのは、エラーが起きると元の場所に巻き戻るようになっていくっていう、一般的なトライキャッチとかだと、帯域脱出してその次のブロックに入るみたいな挙動になるけど、
これはなんかその仕組み上、なんかその一番最初のハンドルを呼び出したところのエラーにエラーが入ってくるっていう、なかなか面白い感じになってますね。
これ一応ですね、由来があって、どこから話すといいのかな。もともとはハンドルとチェックっていうのがラスコックから出てたんですよ。
あ、そうなんだ。Goのプロポーザルでラスコックからそういうのはどうかって出てたってことですか。
Go2が話題になってたときに、エラー処理と一緒になんかこれが出てたんですよね。それもやっぱりチェックが関数呼び出しの先頭にチェックっていうのをつけて関数を呼び出すと、
エラーが発生したときに、なんかハンドルって書いてあるところにフォールバックする動きを出してたのを完全に真似てます。
ほんとだ。知らなかった。いや多分なんか忘れてたんだろうな。確かにこういうのを見た覚えがちょっと思い出してきました。
だいぶ前なんで、そこからエラー処理としてはトライに行ったりとか、クエスチョンマークが出たりとかしましたけど、逆に過去に遡ると実はそれ、プランラインのアレフ言語にもあるんですよ。
アレフ言語自体がもうなくなってしまってるんですけど、アレフ言語にもさすがに名前は忘れてしまったんですが、確かチェックとハンドルと同じような仕組みがあるんですね。
はいはいはい。
語で言うとデファーでやってるようなことを、アレフ言語はチェックとハンドルでやってたっていうのがあって、多分ラスコックはそれを知ってるから、同じような仕組みをプロポーザで出したんじゃないかなと思ってるんですけど、出所は実はそこなんですよね。
うーん、そうなんだ、なるほどな、面白い。まあでもこれは本当に、ちなみにこれってハンドルが呼ばれるじゃないですか、呼ばれるというか、その後にハンドルに巻き戻るときに、その間にあるデファーって呼ばれるんですか?
呼ばないです。呼べないが正解ですね。
呼べないですよね、そこにだって戻ってきちゃうわけだから。
おそらくスタックかG構造体の中には入ってるので、その辺頑張って探せばなんかできるのかもしれないですけど、ちょっとそこまではまだできてないですね。
なるほどね、まあでもディファー使えないとちょっと思わぬ動きになりそうっていうか、だから結構これは生でアセンブラーを触んないといけなくて、
そうか、だからサポーティットアーキテクチャにARM64、AMD64って書いてあるっていう感じなんですね。
はい、その通りです。
うーん、なるほどな、いやー、これは、はい、なんかまあ解説ブログもあるんで、これを読んでもらわないとわからない気がするな、てかこれ読んでもわかんない感じがする。
はい、うーん、まあでも本当はあんまりにもどこにでもジャンプできると壊れるので、本当は同じハンドルを読んだ関数の中でしか戻れませんってしたいんですよね。
はいはいはい。
まあやりたいんですけど、5だと多分型をエクスポートしない小文字始まりにすればそれっぽくできるんですが、関数リテラルって言うんでしたっけ、なんかFuncでその場で関数作る機能があるじゃないですか。
はいはい。
あれを使われると容易に関数の外から読まれるので、なんか難しいなーと思ったりはしてます。
うーん、そうだね、なかなかやっぱり難しい、こういうのを作るのは難しいし、なかなかこういう黒魔術的なことをしようとするとやっぱアラが出てきて、
アラというかどうしても使ってほしくないユースケースみたいなのが出てきちゃうみたいなのがよくわかりますね。
なるほどな。よし、まあだいぶ話したし、ラスコックスさんの話にちょうどなってつながりもいい気がするので、前半はこれぐらいで切ろうかなということで一旦切ります。ありがとうございます。
ありがとうございます。
