藤原さんの発表と感想
おとといはお疲れ様でした。お疲れ様でした。 私史上最高のチューニングということで、いや、発表面白かったですね。
そうですね。ちょっと昔話をしすぎた感がありますけど、懐かしい人が懐かしい。 いや、今日も昔話多めになっちゃいそうなんですけど。
そうですね。 なんか、fujiwaraさんの発表の最後に、チューニングの後にはまた次のチューニングがやってくる、みたいな感じで終わってましたけど、今日無事に解決したみたいで良かったです。
そうなんですよ。デプロイされて、無事にレスポンスタイムが4分の1になりましたね。
すごい。素晴らしい。 僕は何もしてないんですけど。
何もしてないんですか? 原因とか話せることあるんですか?
原因は、何でしょうね。ゲームなんですけど、ソーシャルゲーなんですけど、ユーザーの持っているアイテムを全部返すAPIみたいのがあるんですよ。
それが多くなると、返すデータが多くなってどんどん重くなるみたいなのがあって、その中にループで持ち物をぐるぐるとループしてるとこが遅くて、いっぱい持ってる人がどんどん遅くなるっていう。
なるほど。ありがちな話ですね。
おとといはでも、ユースケベイさんとかも来てて、ちょっとインターネット感がある感じでしたね。
でも、すごく後で藤原さんに言われて反省したのは、やっぱり前の方で圧をかけて座るのは、それは良いとして、ちゃんと相手の発表に頷くとか、レスポンスを返すっていうのは大事だなっていう。
そういう人がいると確かにリズムに乗れるよなっていうのは思いましたね。
アスミカンさんとかがすごいそれをうまくやってたって話を聞いて、初心に帰らないとなと思いました。
反応があるとはないとじゃ全然話しやすさが違いますからね。
OSSとエスプレッソ
いや本当ですよね。だからそれこそもうコロナ禍になってからオンライン登壇とか増えたけども、最初めちゃくちゃ戸惑いましたからね。
そうですね。収録が最悪ですよね、あれ。一人でこう20分とか喋り続けるって誰もいないとこでっていうのがすごい辛かったですね、あれは。
いや収録僕やったことないんですよね、事前収録。でも事前収録辛そうですよね。
辛いですよ。
まだ僕もこのポッドキャストも一人収録まだやってないんで、なんかそういう修行もしかしたら必要なのかもしれないというふうに思ってはいます。
はい、まあそういう感じでこの番組はですね、趣味でOSSをやっているものだというポッドキャスト番組でOSS作家のソムがゲストを交えながら趣味や仕事について話すポッドキャストです。
ということで本日のゲストは藤原さんです。よろしくお願いします。
よろしくお願いします。
じゃあ藤原さんちょっと自己紹介よろしくお願いします。
はい、藤原と言います。TwitterXでも藤原で、僕2017年か4月のツイッターが流行り始めた時にアカウントだけ作ってるんですごくプレーンな藤原っていうアカウントが取れたんですよね、当時はね。
はい、なので普通のロー文字の藤原っていうアカウントでやってて、会社は面白法人火薬という会社でずっとSRE的なことをやってもう十数年みたいな感じですね。
で、最近はOSSを作って結構使っていただいていることが多くて、皆さんにAmazonのECSのデプロイツールのエスプレッソっていうのが最近の代表というか、
おりと人気のあるやつで、そういうの他いろいろ、主に会社でAWS使ってるので、AWSと関連するちょっとした小物みたいなツールをいっぱい作ってて、そういうのでちょっと有名かもしれないですね、界隈では。はい、という感じです。
よろしくお願いします。
よろしくお願いします。
そうですね、もうエスプレッソの藤原さんって感じですからね。
僕と藤原さんは、2011年に火薬にほぼ中途同期入社みたいな感じなんですよね。
そうですね。
で、その頃、そしゃげバブルみたいなのがあって、その頃に結構社員が増えた時に僕はうまく火薬に滑り込むことができて、当時火薬がインフラも増強したいみたいなのがあったから藤原さんが入って、
みたいな感じで、もともと僕と藤原さんはパールつながりで、なんとなくお互いは認知してるみたいな感じだったんですけど、火薬入ってから、それこそ結構密に働くみたいな感じになりましたよね。
僕はアプリケーション開発がメインだったんですけど、藤原さんはそういうデータセンターとかインフラ基盤とかそういったところを結構やられてたり、いろんなアプリケーションのチューニングをされたり、ヘルプで入ったりみたいな、そういう感じでしたよね。
そうですね。当時はまだインフラといってもクラウドとかそんなに使ってなかった時代なんで、いろいろやることがあって。
アプリケーションも当時は書いてたんですけど、僕も全然。どっちかというと得意なのが下回りのほうが得意だったんで、自然とそっちのほうが比重が増えたって感じですね。
そうですよね。お互いちょっと僕も藤原さんもCパンにモジュール出したりとかしてたみたいなところもあって、お互いそういうパールもんがみたいな、そういう認識でしたね。
でも本当にその頃は藤原さんにはお世話になって、藤原さんが結構設計した仮想化基盤みたいなところでアプリケーション作ってたし、その時にシェフとかを藤原さんが持ち込んで、
各アプリケーション開発のエンジニアがシェフを書いて、自分たちで自分たちのインフラをコード化するみたいなことも初めての体験だったんで、すごい良い体験をさせてもらいました。
技術の進化と過去の思い出
そうですね。コードでそこら辺のプロビジョニングを管理するみたいなのはその頃やっと一般化しつつあった時代ですよね。
その前は本当に手で組んだ。
そうですね。パペットとか、まだパペットが多くてシェフが出始めで、まだアンシブルができ始めぐらいの頃ですよね。
そうですね。
まだハシコープとかも出てくる前でそれこそ、ベイグラントとかはみんなその後使い始めてとか、ドッカーとかも2013年とかだから、もう全然今からすると全然違う時代ですね。
そうですね。まだ普通に仮想マシンがしかなかった。コンテナで動かしてるサービスとかほぼなかったですね。
あとGoogleとかには当時からあったんでしょうけど、一般のウェブ業界の会社には普及してなかった時代ですね。
そうですね。とりあえず仮想サーバーで仮想化基盤があるだけですごいみたいな感じでしたからね。
だから藤原さんと当時作ってたゲームとかだと、どれぐらいのスペックのマシンが欲しいですかみたいなの聞かれて、
じゃあ2コアでメモリ8ギガでみたいなやつを何台並べますかみたいな話をして、それで切り出してもらってたみたいな、そういうやり取りをしてたのを覚えてます。
当時はVMはあったんですけど、Ioまでが仮想化できてなくてですね、当時うちらで作ってたやつは。
だから仮想マシンをコピーしようと思うと、本当にディスクをコピーするという何十ギガのディスクイメージをマシン間でコピーしないといけなくて、それがめんどくさかったなっていう思い出がありますね。
めんどくさかったし、Ioとかネットワークに負荷かかるから、あんまり高速にやると他のサービスの影響出ちゃったりとかして、すごいめんどくさかったですね。
なるほど、ナイスとかかけながらゆっくりやるみたいな。
そうそう、転送量絞ってコピーしなきゃいけないけど、そうすると遅いんですよね、当然ね、コピーするのに時間かかってだるいしみたいな、そんな時代でしたね。
時代ですね、本当に。だからそれこそもうそういう、それこそ甲子園シリーズみたいなのがヒットしたから、ソシャゲ王カヤックさんが結構力入り始めて、僕もそれに関わったりしたんですけど、それが今度終了するっていうことで、なかなか感慨深いものがありますね。
そうですね、カヤックがやってるソシャルゲームも全部終わっちゃうんで。
そうなるんですね。
そうなんですよ。新しいタイトル出たんだけど、なかなか新しいのはヒットしないで、古いのはずっと生き残っていて、それがもうすぐ全部終わっちゃいますね。時代の流れというか感じもしますが。
ソシャゲも2本目3本目のヒット作出すの難しいですからね、パズドラとかもまだ頑張ってるし、割と最初出たやつがずっと粘り続けるみたいな戦いになることは多いですよね。
そうですね。
モンストとかもまだ頑張ってると思うし。
ということで今回は、この番組のタイトルにフィットした話でOSSの話をしていきたいなと思ってるんですけど、藤原さんがOSSに関わり始めたのとかって結構大昔になるのかなと思うんですけど。
そうですね、大昔ですね。
どういう感じだったんですか。
僕は1998年から仕事してるんですけど、前世紀から。最初の頃はOSSとかあんまり意識しないで、会社にあった秘伝のライブラリーみたいなのを使って開発してたんですけど、散々炎上しまして、めっちゃ大変だなってなって。
その時に2000年の12月にLinuxとPerlとRubyのカンファレンスが京都であったんですよね。
ちょっとそれに行かせてくれって言って、それに行って、それと同時にWebDBプレスがちょうどそこで発刊された時なんですよ。
それをカンファレンスに行って話を聞いて、さらにWebDBプレスを読んでみたら、最初の特集だったかな、関東のほうの特集でCPANモジュールを使ってフレームワークを使ってアプリケーションを開発するみたいな話が載ってて、これをやったらいいのかと思ってですね。
それからCPANモジュールですね、Perl使ってたので、それをいろいろ使ってシステムを組むようになってみたいなところからですね、最初のところは。
その頃、LinuxとPerlは使ってたんですか?
Linuxは使ってました。本当に最初はWindowsサーバーだったんですけど、Windowsサーバーの上でPerlを動かしてたんですけど、その後にLinuxが結構流行ってきて、それでサーバーはLinuxでやって、その上にPerlとCGIですね、最初はね。
そうなんですね。その頃だとまだLinuxもそんなに主流ではなくて、それこそUNIXだとまだSolarisとかそういうものも使われてた時代なのかなと思うんですけど。
ソラリスはお高いところが使ってましたね、お高い。ちゃんとした会社が使ってました。SIAさんみたいなところとか。ソラリスもPCソラリスとかありましたけどね、当時は。
あとはFreeBSDとLinuxが当時の会社だと使っていて、Linuxの方が流行ってきたんでLinuxみたいな感じでしたかね。
そうだ、そうですね。FreeBSDありましたね。僕も2000年ぐらいに大学入ってましたけど、最初にパソコンをDynabookをWindows 2000とFreeBSDのデュアルブートにしてた覚えがありますね。
そうですよね、FreeBSDがよく使われているイメージでしたね。
そうですね、やっぱりマルチタスクの時のスケジューラーとかがまだ当時Linux出始めであんまり強くなくて、そこら辺にFreeBSDだと負荷が上がっても動きやすいみたいなのが当時でしたね、2000年いくかいかないかぐらいの頃は。
もう今ではなんともですけど、通じない話ですけど。
FreeBSDまだ結構使われてますよね、さくらさんとか。
それはそれで別に人気があるとか。
そうですよね。
今日の話としてOSSのCLIツールの設計の話みたいなの書かれてますけど、これはどういったことを話そうって思ってたんですか。
そうですね、なんかOSSって例えば、僕ちっちゃいものしか作らないので、なんかワンアイディアで作るじゃないですか、これができたらみたいなとき。
その時に仕事で作るアプリケーションとかだと結構先に設計をしたりするじゃないですか。
なんかクラスがこうあってとか、そういうのを設計するんですけど、ちっちゃいOSSのツールを書くときってそこまでしないくて、
なんかいきなりドーンって書いちゃって、それでその後どう育てていくかみたいになるんですけど、
最初にどこら辺まで想像してからクラスとか、ゴーで作る場合型ですけど、そういうのを作るのかなみたいなのがちょっと自分のやり方しかわかんないから、他の人はどうなんだろうなみたいな感じですね。
藤原さんだとどういう感じでやられるんですか。
僕は最近だと、テンプレートのリポジトリがあって、そいつをまずコピってきて、チカンしてそのパッケージ名とかだけ直して、
そうするとCMDすらコマンド名すらメインにメイン関数が置かれて、あとパッケージが一個だけポンとあるみたいな状態なんですね。
そこから何をやろうかなと思うと、だいたいコンフィグ型みたいなのを書きますね、ゴーだと。
コンフィグ設定ファイルの型みたいな、ゴーじゃないRとかRubyとかで書いてた時って結構コンフィグをわざわざ何か意識しないで適当なハッシュみたいなものを設定を入れる箱にしてたんですけど、
ゴーだとそれできないので、そうすると一応ちゃんとストラクトを作って、こういう設定項目があるからフィールドを作って、みたいなことを最初にコンフィグを書くなみたいな、
コマンドラインインターフェースの設定
そのコンフィグを読み込むコードをどこかから持ってくるなりライブラリ使うなりして、そこからそれをメインで読み込んで、
そこからそんなに細かくわけないんで、一つのパッケージの中でゴリゴリと一直線書いていくんですけど、最初にコンフィグを書くなって思うのが、ゴーになってからやるようになったなっていう感じがしますね。
なるほど、確かにそれはありますね。僕も似たような感じで、僕の場合だと、僕もひな形があって、一応ゴジルっていうひな形作成ツールがあるんですけど、それを使って、かなりオレオレのツールなんですけど、
それでひな形を作って、そうすると藤原さんと同じく、cmdすらコマンド名すらメイン.goと、プロジェクトルートにパッケージ名.goみたいなものがあって、書き始めるみたいな感じですね。
僕の場合はコンフィグみたいなものを、コンフィグっていう型名を作ることはあまりなくて、どちらかっていうと、動くアプリケーション、サブコマンドだったらサブコマンド、コマンド単位でストラクトを定義して、
そこにプロパティを詰めて、そいつのランメソッドみたいなのが呼ばれると、動く、サブコマンドなりコマンドが動くみたいな形にすることは多いですね。
なので、コンフィグとかは本当に明示的に、コンフィグファイルみたいなものを作るときに、タイプコンフィグストラクトみたいなのを作って、そこに割り当てるみたいな感じですね。
アプリケーションの型を先に作って、そこに属性が入っているので、そこに埋めるのは後からやるみたいな感じですね。
それこそこのPodcastの配信ツールであるPodbirdっていうのを作ったんですけど、それで初めてやったのは、インターナルを切るっていうのは初めてやりましたね。ほぼ初めて。初めてではないんですけど、でも自分のコマンドラインツールとかだと初めてかな。
一番上のレイヤーはCMDスラパブリッシュとかCMDスラビルドみたいな、そういうサブコマンドごとのエントリーポイントだけを置いておいて、実際の処理はインターナル以下に詰め込むみたいな感じにしましたね。
ちょっと若干大きめのアプリだったので、そういうふうにしないと結構見通しが悪くなるなっていう感じだったので、そういうふうに分けたみたいなのをやりました。
そうですね。割と推奨はされてますよね。アプリケーション作る場合、外から使われてほしくないのはインターナルに押し込んどけみたいな話は結構聞いてますよね。
そうですね。
たまにパブリックとプライベートの型とか関数とかあんまり意識しないで作ってしまって、置かれてるから外から使おうと思えば使えるみたいな状態になるじゃないですか、インターナルに入れとかないと。
そうなって、これ何か誰か使ったら変更できなくなるかなとか一瞬思うんですけど、アプリケーションなのでライブラリとして使うやつが悪いと思って遠慮なくぶっ壊したりしますけど、そこの互換性はね。ライブラリの場合は気にしますけど。
いや僕もそうですね。CMDすらメイン.com形式だとリポジトリトップにあるパッケージってすごいオープンになっちゃうから、それのランメソッドだりCMDメソッドかわかんないけど、そこにあるパブリックのやつってもうどこからでも呼べるようにはなるんだけど、他の人たちからは。
でも別にそれ呼ぶのそもそもおかしいでしょっていう感じがあるから。
それを期待してる方が悪い。
そうそう。わかります。
でもテラフォームが昔インターナルじゃなかった時代が結構数年前あって、なんかテラフォームすごい人気が出ちゃったもんだから、テラフォーム関連のOSSみたいなものがそのインターナルになってパブリックのテラフォームの関数を当てにして使い始めてしまって、それであるときハシコープがテラフォーム全部インターナルにするからって行動全部インターナルに持って行って、そこら辺の人たちがみんなキャーってなったらしいっていう話を聞きました。
僕はそういう使い方をしてなかったので全く関係なかったんですけどね。人気が出るとそうですよね。依存しちゃう人っていうのが出てくる。
大きいとそういうこともあるっていう感じではありますかね。とはいえなんかビルドが壊れてくれる分には別にいいかなっていう感じは個人的にはしますけどねって思って。それが静的片付けのいいところだから、そこは困ったらなんとかしてくれっていう感じはありますね。
そうですね。動的言語とひっそり動かなくなるだけですからね。そこがだいぶ違う安心感。そういった感じかな。何でしょうね。コンフィグを書くのって何でしょうね。コンフィグってわりと外界とのインターフェースというかツールの外界とのインターフェースじゃないですか。
あとCLIのフラグとかもそうで、そこはわりと変えづらくて決めてしまうと。そこを変えると使ってる人がいきなり動かなくなるんで、メジャーバージョンアップで破壊しますよって言ってからじゃないと変えづらいところで、それ以外のところは好きに書き換えちゃっても別に誰も困らないみたいなところなので、
ちょっと外界から見てどういうところを渡してほしいのかみたいなところを最初に意識するかなっていうのがそういうふうな書き始めをするかなっていう感じですかね。
そうですね。僕もやっぱりコマンドラインフラグみたいなものがどういう振る舞いをするかみたいなのは決めちゃって、E2E的にそれのテストは書いておくようにして、最低限エラーなく動くようにするみたいなところは担保するみたいなのが多いですかね。
僕の場合だとフラグをパースして、パースして取れた値をアプリケーションのストラクトに埋め込んで動かすみたいなことが多いのと、なるべくコマンドラインフラグだけで最初はやって、
ある程度、現実的には環境変数も読むようにして、設定ファイルとか持たせるのは結構最終手段ぐらいの感じで僕は考えてたりはしますね。
そうですね。ちょっとネストした構造体とかが必要になるとどうしてもファイルじゃないと厳しいみたいなのがあるから、そういう複雑な設定を受けれるやつはしょうがなくてファイルにしますけど、それ以外はCLIで引き数だけで動くというのが一番楽ですからね、使うほう。
なんかCLIパーサーがKong使ってるっていうのを最近ツイートされてたじゃないですか。昔Kingpin使ってたと思ったけどなと思って、ちょっとさっきログを見に行ったら、本当だここで切り替わってるみたいなのを思ったんですけど、Kongはどういうところがいいんですか?
Kongとその利点
Kingpinの作者は同じなんですよ。Kingpinの後継ツールというか後継ライブラリといって、Kingpinはもうメンテされてなくて、同じ作者はKongを作ってこっちをやるからってことになって、単にメンテされなくなったからっていうのもあるし、だいぶ使い勝手が良くなってる感じしますね、Kingpinよりも。
何がいいかっていうと、いろいろあるんですけど、世の中にCLIフラグパーサーあるんですけど、どうもいまいち使ってしっくりくるものがなかったんですけど、Kongは型を書いてその型に全部引き数とかを埋めてくれるんですね、一発で型を書いておくと。
例えばこの属性は環境変数のこの値から読む予定のセットでアトリビットにつけておくと勝手に読んでくれるとかあるので、そのCLIでどういう引き数を取るかみたいなのを全部型のネストした感じ、サブコマンドがあったらサブコマンドのストラクターがさらにネストするんですけど、
そういうのを作っておいて、あとはパースをトンとやると値が埋まってくるので、非常に使いやすいという感じですかね。
いや、これいいですよね。これ、昔GoFlagsっていう似たようなライブラリがあって、僕それ好きで使ってたんですけど、あんまりメンテされなくなっちゃって。かつその後、結構Kingpinとかが流行って、今はたぶんCobraとかも流行ってると思うんですけど、
割とあんなにDSLっぽく、言語ないDSLっぽくルールを書くよりかは、単純にこういうふうにちゃんとKongみたいにストラクトのコメントアノテーションみたいなところに書いておいて、自動的にストラクトに入れてくれるっていうのはすごいわかりやすくていいですよね。
そうですね。CLIパーサーと言いつつパーサーじゃなくてフレームワークみたいになってることが結構多いじゃないですか。他のやつって。そうなるとそのフレームワークに書き方を強制される感じがあるのが使いづらくなって思っちゃうともううってなるので、Kongの場合は一応そのフレームワークっぽくも書けるんですけど、
単にそのでっかいストラクトをネストしたストラクトに値を埋めるだけっていう使い方ができるので、そうするとパースしてあとはそこに埋まってる値を使うだけなんで、あとここから先は自分でやれるっていうのがいいところですね。そういう意味では好きにパースが終わった後は好きに書けるんで。
これはそう僕はあんまりちゃんと見てなかったんですけどいいなって思いました。僕も結局なんかフラグパースした後にこういうふうにアプリケーションのストラクトに詰め替えるみたいな処理をしているので、それが別にそのパース一撃でやってくれるっていうのはめちゃくちゃいいなっていうのはありますし、
それこそコブラとかよく使われてるんですけど、僕はあんま好きじゃなくて依存が多すぎるし、なんかもう一つのものでトムルとかヤムルとかJSONとかも読めるみたいなの作れるけど、別にそこまで求めてないし、このライブラリ依存するとそれこそリノベートとかがガンガン依存ライブラリのバージョンアップを上げてくるから面倒くさいなみたいな気持ちになるので、
はい、これはいいなと思いました。
お気に入りですね、最近は。
僕は本当に何も使わずに標準のプラグだけでサブコマンドを含めて書くか、それかRFAVE CLIっていう、昔Code Gangster CLIってやつだったんですけど、それを使うことが多くて、サブコマンドとか比較的シンプルに書けるのでいいんですけど、
これもアプリケーションの第一引数がコンテキストっていう名前なんですけど、これはすごく歴史的なヒストリカルリーズンにより第一引数がコンテキストって名前なんだけど、これは標準のコンテキストがない時代に第一引数を独自コンテキストにしてるっていうところがずっと不細化していて困ってるみたいな感じで、
これはV3が多分もうちょっとで出るんですけど、それはもう本当に第一引数にコンテキストコンテキストを取るようにして、第二引数にこれまでコンテキストって言われたものを取るようにするみたいな形にするっぽくて、妥協案としてはいいかなっていう感じでは思ってますね。
歴史長いとね、Goのコンテキストが結構後から入ったから、それの整合性が取れないみたいなのが確かにありますね。
そうですよね。Goのコンテキスト、後から入ったと思うか、割と初期からあったかと思うかありますけど、僕らにとっては結構後から入った感はありますよね。
昔からGoを使ってた人にとっては後から来た感じですね。最近始めた人は最初からあるんで、なんとも思わないでしょうね。
そうですよね。もう皆さんGoモジュールとかも最初からあると思ってるし、すごく今から思うとGo開発楽になったなっていうのはありますね。
藤原さんと言えばエスプレッソ、ラムロールとか、かつぶしとか、そういうECRMとか、いろいろ出してますけど、割とそういう自分の中で気に入ってるOSSとか、
これはあんま知られてないけど、これは結構いいOSSだみたいなのってあります?
そうですね。エスプレッソとか人気があるんで、もちろんお気に入りと言えばお気に入りなんですけど、すごい地味なやつで言うと、SQSJFRっていうのがあるんですけど、
これは何かっていうとですね、クロンタブのファイルがあるんですよ。クロンタブのファイルを読んで、そのスケジュール通りにSQSにクロンタブのコマンドの情報をメッセージとして流してくれるっていうやつですね。
これさっきも言った10年続いてるゲームがあるんですけど、それを途中でECSにしたんですよ、EC2だったとき。それの時にそのクロンタブがものすごいいっぱいあって、しかも孫文さんそこら辺知ってるというかやってたってわかると思うんですけど、
クロンタブがすごい何百行あって、しかもそれのテストも書いてあるんですよね、しっかりね。このコマンドはこうでなきゃいけないみたいなテストが書いてあって、それをクロンタブは捨てたくなくて、捨てられなくて、
なんで、それはそのまま維持した上で、ジョブをSQS経由にしたかったんですね。というので、クロンタブのパーサーのライブラリを使って、この時刻になったらコマンド名とか環境変数の書いてあるやつとか、そのコマンドをJSONにしたものをSQSのメッセージとして給意に送ってくれる。
それを実行するのはまた別の誰かがいるんですけど、というやつですね。これあといいのがね、2つ動かしておくと、SQSのFIFOQってあるじゃないですか、同時に重複したメッセージを送っても1個にしてくれるやつ。
なんで、2つのプロセスを動かしておいて別々に、それぞれ同時に一斉のでSQSに送ると、SQSのQが配達してくれて1個だけ取れるんですよ。なので片方落ちても大丈夫で、多重化が勝手にできるっていう作りになってて、
なので、よくクローンを動かしているホストが落ちたら全部止まったみたいなシングルポイントになりがちなんですけど、そこも解消できるし、そういう地味だけど、しかもうまく動いたんでね、お気に入りのやつがありますね。
なるほど、それめちゃくちゃいいですね。僕もクローン周りのツールたくさん作ってきたし、それこそクローンの仕組み整えるのをかやく時代にやってたから、それがそういう形で、もう誰も使わない、他の人あんま使わなさそうな独自隙間家具になってるのが、これはすごいいいですね。
かつ、確かにハイフォーキューすごい、多分パフォーマンスがあんまり出ないからってことで、使われてない、使うケースあんまり見ないですけど、それこそそういうクローンの実行みたいなものをたまに流すみたいな感じだったら、本当にドンピシャなユースケースな感じがするので、確かにすごいいいですね。
うまくできたなと思って、一人でホクソエンディングタイプのOSSですね。
そんな感じですね。
お気に入り、いろいろあるけれども、最近R2 Syncっていうコマンドラインツールを作って、これはラストで書いたんですけど、初めてラストで書いて、一応ちゃんと動くものができたので満足してるんですけど、
これ僕のこのPodcastの音源配信に使ってて、あるディレクトリにmp3ファイルが並んでて、それをR2、Cloudflare R2っていうS3みたいなやつにSyncしてくれるみたいなやつなんですけれども、
これがですね、毎回素朴にプッとしてたら、遅いしお金もかかっちゃうんで、お金はほとんどかかんないんですけど、コンテンツの内容が一緒だったらスキップするみたいなことをしてほしいなって思って作ったっていう感じなんですよね。
S3とかもそうなんですけど、R2もほぼ互換の内容なんで、EタグにMD5のハッシュが入ってるので、それを比較すれば、実は一致してるかどうかってなんとなく取れるんですけど、そこの比較してるツールが多分あんまないんですよね。
だいたいそのAWS S3のSyncとかのコマンドも、たぶんコンテンツレングスとかが一緒だったら同じと見なしてみたいな感じでスキップするモードがあるんですけど、それだとすごいちょっとやだ、だからちゃんとハッシュで比較したいみたいなのがあって作ったっていう感じで、うまく動いてるので、これは満足してますね。
R-SyncのR2番ってことですね。
そういう感じですね。これもちょっとかなりオレオレツールっぽい部分があって、それこそS3にアップロードするツールとかR2にアップロードするツールとかも並列でアップロードができるし勝手に並列でアップロードされるものっていうのがあって、
だいたい8メガを超えると並列でアップロードされちゃうみたいな、ファイルを切り刻んで並列でアップロードしてガッチャンコするみたいな感じになってるものが多いんですけど、そうするとハッシュ値の作り方が変わっちゃうんで、その意味でハッシュ値の整合が難しくなってるっていうのがあるんですけど、このツールはプットするときも一括で上げるっていうだけのことをしていて、
なので、このツールで上げればハッシュ値の位置を見るのも簡単みたいなのがあるので、オレオレツールっぽい感じではありますね。
でもこれを作って、ラストなんかすごいコマンドラインツールめっちゃ多いから最近、クロスビルドとかそういうの結構ゴー並みに簡単なのかなって思ったら、思ってたより難しくて、
クロスビルド環境を作ったりするのが難しくて、ゴーよりが難しかったので、やっぱゴーはよくできてるなっていうのをすごい改めて思いました。
そうですね、ラストのCLIツールやたら最近多いなっていう感じしますけど、ビルドの遅さとかも気にならないですか?
いや、ビルドもすごい遅い。すごいでもないですけど、結構遅いですね。なので、結局手元でシェルスクリプトを書いて、それでそのDockerを動かしてLinux用のARM版、Intel版、MacのARM版、Intel版みたいなの作るみたいな感じのシェルスクリプト書いたんですけど、
普通に数分ぐらいかかっちゃうので全部回すのに、もうゴーとは運命の差だなみたいな感じにはなりました。
なるほどね。ラストはまだあんまり触ってないので、でも最近なんかね、ChatGPTとかにこのコード移植してっていうとそれなりに書いてくれるから取っ付けやすくなりましたよね、他の言語もね。
これは本当にその通りですね。ラストはそれこそ、僕らが憧れるタイプスターさんとかが前からもういいよって言ってる言語なんで、早く使ってみたいなと思ってたんですけど、ちょうどよく書くチャンスがあってよかったなと思っているとこですね。
あとはあれですかね、エスプレッソ。藤原さんといえばエスプレッソで、僕もそれを真似して作ったECスケジュールっていう、ECSのスケジュールジョブを管理するツールを作っていて、エスプレッソタッグみたいな感じでいってくださっていて、ありがたいなと僕的には思ってます。
そうですね。去年エスプレッソだけのイベントっていうちょっとマニアックなイベントを開催していただいて、エスプレッソについての10分トークが9本並ぶっていうちょっとなかなか際もったイベントだったんですけど、あれはよかったですね、でもね。
あれよかったですね。僕も話をしましたけど面白かったですね。なんか似たようなイベントまたやるんです。
藤原ウェアカンファレンスの企画
モゾニオンさんがヤプシの時に話しかけてきて、藤原ウェアカンファレンスをやりたいんですけどいいですかねって言われて、いいよって言ったので、来年かな1月とかに予定企画を今やってるところらしいんですけど、僕のOSSの勉強会的なイベントをやるって言ってました。
また何の内容は何もわかんないですけどね。ありがたいことですね、ほんとね。
いやー、それいいですね。面白そう。僕はハテナのCTOのモテメンさんから結構メンテナンス行き過ぎたりとか、結構モテメンさんが作ったプロダクトみたいなのもあるんで、そういうモテメンカンファレンスをやりたいなと思ってたんですけど、先起こされた感があり、逆にちゃんとやりたいなという気持ちが巻き起こってきました。
いいですね。ありがたいことです。なんかね、エスプレッソでだいぶモズニオン前に勤めてたところで、あれがなければ死んでいたとか言ってたので、だいぶ役に立ったので、恩を返してくれるみたいですね。ありがたいことですね。
僕もエスプレッソを助けられました。そんなところかな。
ということで、いろいろ話してきましたが、前半はこれぐらいにして、後半は多分皆さん聞きたいと思う。藤原さんと言えばイスコンという感じだと思うんで、イスコンの話をしたいと思います。ということで、前半はこれぐらいです。ありがとうございました。
はい、ありがとうございました。
