OSSとプルリクエストの楽しみ
いや、最近、趣味のOSSがすごい楽しくてですね。なんかめっちゃプルリクエスト送ったりしてるんですよ。
そうなんですね。
いや、しかも結構、クロードコードマックスを契約したので、結構それで一緒にレビューしてもらったり、プルリクエストコメント書いてもらったりとか、いろいろしてるので、はい、はかどっております。
本当に、なんか私もなんかずっとプルリクエストが結構来ているので、これをずっとなんかレビューしたりとか、なかなか追っつかなかったりとかしながら、いろいろ、最近は趣味のOSSやってますもん。
いやー、そうですか。大変ですね。
はい、です。
ということで、この番組は趣味でOSSをやっているものだという番組で、OSS作家のソムがゲストを交えながら、趣味や仕事について話すポッドキャストです。
はい、今日のゲストはk1Lowさんです。よろしくお願いします。
よろしくお願いします。
じゃあ、k1Lowさん、自己紹介お願いします。
はい、私は今、テイラー株式会社というところでプロダクトエンジニアをやっています。k1Lowという名前でインターネット上では活動しているので、ソフトエンジニアですね。よろしくお願いします。
よろしくお願いします。転職されてどれぐらいでしたっけ。
まだ使用期間で5ヶ月ですね。
使用期間半年あるパターンってやつですか。
そうですね。言われたのは、とりあえずあるけどあんまり使ってないって言われてますが、一応確か6ヶ月経ったと思います。
なるほど、なるほど。そうですね、ああいうのはだいたい、とりあえず設定するみたいな感じになりますからね。そういう、なんていうか、就業規則みたいなのを定めるときとか、雇用契約を。
そうなんですね。そうですよね、ご転職されてるなーってのを観測してました。
k1Lowさんとは、たぶん初めてお話ししたのは、2019年のGO!コンファレンス福岡とかだと思ってるんですけど、そうですよね、きっと。
おそらくそうだと思っています。声をかけていただいたのを覚えてます。
そうですよね、そうそう。お声掛けをしたのをたぶん覚えていて、なのでその前からちょくちょくお互いなんとなく、そのGO!でOSSを書くみたいな文脈で、なんとなく意識してたみたいなところがありますよね。
はい、そうですね。
なんかそれこそ僕はフィルトっていう、k1Lowさんが作ってるOSSが好きで、結構使ってたんですよね。このフィルトっていうやつ、今でも使ってます?
えっと、私は今は使わなくなりましたね。
はい、そうそう。
ちょうど転職をしたのと、やっぱり時代が変わってきたので、はい。
いや、時代が変わりましたよね。そうですよね。このフィルトがどういうものか、ちょっと説明していただいていいですか?
はい、フィルトはログを見るためのツールなんですけれども、テイルとかテイル-Fとかコマンドを使ってログを見ると思うんですが、
その時に、そのログに対して、さらに追加でコマンドをかけて、例えばグリップをかけたりとか、オークをかけたりっていうのを、
Try & Errorでインタラクティブに何度でもかけることができるというツールですね。
はい、そうですよね。これめっちゃ便利で、そのテイルとかで流しっぱなしにしてるストリームに対して、
ちょっと止めて、正規表現とかで絞り込みかけると、そのログだけを流すみたいなようにしてくれるみたいなやつで、やっぱりすごく便利でしたよね。
でも最近は、あんまりターミナルでログをテイルするなんて、そんな野蛮なことはしなくなったので、あんまり使われなくなったっていう感じですね。
はい、そうです。本当に使わなくなりました。
最近ログは、どっかのログを見るぐらいじゃないですかね。コンテナのログを。
手元とかだとそうですよね。あとはもう大体、ウェブ画面からそういうログエクスプローラー的なやつでポチポチ検索するみたいな、そういう感じですよね。
はい、そうです。もう本当に見なくなりましたね。
でもそれは会社が変わったみたいなところも影響されてるんですか?
そうですね。やっぱり、もともと前職がGMO Paperballという会社で、インフラも含めて触るようなところで働いていたので、そういう意味だとログはよく見ることが多かったんですけど、
そうですね。転職して、本当にプロダクトをひたすら書くみたいなところになったので、本当に見なくなりました。
いや、そうなんだなっていう。確かに僕も本当、SSHとかしなくなって長いからなっていうのがありますね。
.SSHコンフィグ、すっごく綺麗ですよ、今。
そうなりますよね。本当、最終的にはSSH必要でしょ、みたいな思ってた時もありましたっていう感じですね、本当に。
そうですね。今はオブザーバビリティも含めていろんなツールで綺麗にビジュアライズされて見えますからね。
いや、すごい。僕、ケイイチローさんと同じようなニーズでツールを作ってる部分があると思ってて、やっぱりその技芸の高度によるボトムアップっていうふうにおっしゃってるのがすごく好きで、
僕も開発バターなので、歴戦のオペレーションエンジニア、インフラエンジニアみたいな人がワンライナーとかでガリガリいろんな調査をサーバー上でやるみたいなのを結構かなわないから、
じゃあ便利ツールを書いて運用を楽にしようとか、そういうモチベーション僕にもあったので、この技芸の高度によるボトムアップっていう言葉すごい好きです。このブログとか覚えてますか?
そうですね、たぶんこれは前職でアップアップしてる時の、なんかやっていくぞという気持ちでやったと思うんですけど、そうですね、本当に覚えてはいますし、たぶん結局最後までこんな感じでした。
やっぱりすごい人はすごいインフラの方とか、その他にもやっぱりすごい人たちを肩畳み見ながらやっていたので、ここはずっと何とかしてっていうところは思ってましたね。
そうですよね、ペパポさんはやっぱり今でもそういう物理インフラを結構ちゃんと抱えてる会社ですしね、そういう意味ですごく歴戦のエンジニア、オペレーションエンジニア、インフラエンジニアがいらっしゃるっていうイメージがあります。
あとはそうですね、同じゴーカンファレンス2019で、僕がそのゴーでツールを量産する僕の方法っていうのを発表したんですけど、これを結構、なんかこれ今読み返すと我ながらいい発表したなって思ってるんですけど、
まあでも結構圭一郎さんも感銘を受けてくださって、なんかいろいろ感想を書いてくださったり、ライブラリー書かれてたりしてるのがちょっと印象に残っています。
もう前からそうですね、ソムさんはそういうツールをめちゃくちゃ作る人っていう感覚でずっと見てましたし、やっぱりこういう感じになりたいなと思って見てた中で、
当然作る方法に関しては共感するところもありながら、それぞれ一つ一つの深い思いというか、こういうところにこだわってとか、ここがどうしてもなんとかしないといけないんだみたいなのはやっぱり響いたっていうのはありますね。
なので今回だと作ってものとしては、なんでしたっけ、そうですね、エグゼクっていうのを作った、そうですね、私のやつはエグゼクってやつですけど、もともとはソムさんのツールコマンドを停止するっていうところのページの実装から、なるほどそこまでちゃんと気をつけなきゃいけないんだと思って作りました。
そうですね、この時ソムタイムアウトっていうコマンドをタイムアウトさせるコマンドの、コマンドっていうか、じゃなくてツールの紹介をしたんですけど、それに影響を受けて、ケイイチローエグゼクってやつを作られて、しかもそれが今これから話そうと思ってるデックの中でも使われてるのを見て、ちょっとニヤリとしてしまいました。
ここもですね、ちょうど今の職場でもこの話をすることがあって、ソムさんがやっぱりここに課題意識を持って解決方法を作ったんですけど、私はさも自分が考えたかのようにエグゼクでですね、こうやってやっぱり抜粋でやってるのはうんぬんかんぬんっていう話をしったかで話したのは最近です。
デックツールの紹介
そうですよね。いやでもすごい良いと思います。タイムアウトは僕のすごいGoの初期のライブラリなんで、結構インターフェース的に微妙なところもちょっとあるんですよね。でも使ってるから使ってるみたいなところはあるんですけど、ケイイチローエグゼクはやっぱりそのタイムアウトだけじゃなくて、そういう正しくコマンドを実行するっていうところにフォーカスされてるし、
新しく作られた後発の綺麗さみたいなのもあって良いなと思っています。ありがとうございます。ということで、いやなんか元々僕すごいケイイチローさん呼びたかったんですけど、ポッドキャストに。ちょっと今回はちょうどいい関わる機会があったのでお呼びしたっていうのがあります。
そうですね。今日も関わってましたね。
いや今日も関わってましたね。ちょっと長い一周をあげちゃったりしていました。ということで、デックですね。ちょっとそのGoogleアビリティというかそのユニーク性のためにケイイチローデックって僕は結構意識的に書いてるんですけど、そのデックっていうツールの話をしたくて、今日はちょっと来ていただきました。
じゃあこのデックってやつがどういうツールか紹介していただいていいですか。
簡単に言うと、マークダウンからGoogleスライズのプレゼンテーションを生成するためのコマンド、CLIコマンドになります。
元々のオリジナルというのはGoogleがサンプル的に作っているMD to Googleスライズというツールがあったんですけれども、それの体験が良かったので、私のスライドの作り方にできるだけ合わせた形で作り始めたっていうものになります。
これがすごいめちゃくちゃ便利なんですよねっていうのがあって。
ありがとうございます。
それこそなんとなく使ってる人がいるなっていうのは見てたんですけど、最近ちょっと仕事先でプレゼンを作る機会があって、いつもの雑なHTMLプレゼンじゃなくて、ちょっとしっかり作りたいなって思ったときに、
でもいつもマークダウンでプレゼン資料を作ってるから、それを踏襲したいなっていうことで、以前マークとかも使ってたことはあるんですけど、せっかくなんでデックを使ってみようということで使ってみたら、やっぱりかなり体験が良かったですね。
ラコラコさんとかタドさんとか、あの辺がかなりしっかり使われていて、あとハンハンさんとかその辺が使ってるから、僕としてはかなり美味しい収穫機に使うことができてるなっていうのを感じているところです。
そうするととはいえ、今さらにそこに追加でどんどん改善と安定化と機能追加がソムさんからどんどん来てるので。
そうですね、なんかもうめちゃくちゃ暇なのをいいことにめちゃくちゃ送ってしまってるみたいなのがありますね。
ありがとうございます。
いや、でもその、たぶん圭一郎さんが紹介されてるときとかって、やっぱりその画像対応とかコマンドライン、コード文字列の画像みたいなのの扱いみたいなのがなかったときなんで、
でも今もうその対応が入ってるから、もうめちゃくちゃ便利ですよ。なんかその辺の二度手間がなくて、本当にマークダウンとスライドのテーマだけをいじっていれば、いい感じにデザイン的に統一感の取れたスライドが作れるっていう感じなので、めっちゃいいなって思っています。
ありがとうございます。
マークダウンの改善プロセス
もともとはもっとシンプルにマークダウンの過剰描きがいい感じにある程度の形でGoogleスライドに行けばいいなって形でも、本当にそれだけやってたんですが、
コラコさんが使い始めて、最初はバグ報告だったんですけれども、最後に良かったのと改善ポイントっていうのを上げてくれて、私の中ではすごく、もともとは腰が重いしもう目を背けてたところだったんですけど、そう言われたらやるしかないなと思ってやって、それで終わったと思ったんですよ、私はもう。
そしたらソムさんが見つけて、ソムさんがまたここもこうあるべきなんじゃないかと、これこういう機能あったらいいよねっていうのがどんどんきて、確かにと思いながら今やってる感じですね。
いやそうなんですよね。ちょっとね、後でも話そうと思うんですけど、ちょっとめんどくさいオタクに見つけられてしまったんじゃないかなっていう感じはね、していますね。
ちょっとかなり興奮してプルリクエスト爆撃みたいな感じになっちゃってるんで、すごくさばいてくださってありがたいなっていうふうに思っています。
いや、またその中でもやっぱり一つ、私結構コマンドライン、ソムさんも結構作ると思うんですけど、私も結構コマンドラインツールとかを作りがちって作る人なんですけど、結構私なりにこだわり持ってるんですよね。
やっぱりそのコマンドラインのインターフェースはこうあった方がいいとか、このツールにおいてはこっちがいいとかいうのをやって、今回のデックもそれなりに考えてやったんですが、
ソムさんにですね、いやこのインターフェースよりもこういうことができるからこっちがいいっていうふうに、しかも一旦諦めたものをソムさんから後からこれだったらできるはずだっていうのを提案してもらい、そっちがブレイキングチェンジでデフォルトにせざるを得ないようなアイディアだったので、これがめちゃくちゃ悔しかったです。
そんな悔しかったんですねっていう感じなんですけど。
なんかソムさんもないですかね、OSSとかツールのこの部分にはこだわりがあるみたいなところで、私はそのコマンドラインインターフェースはすごいこだわりがあるし、できると思ってた。
それなりに自分でそのことについて語ったこともあるぐらいなのに、まさかのここでさらに上を当然のように行かれてしまって、上っていう話じゃないですけどやっぱり思いつかれてしまって、すごいなんかこうクソが悔しかったですよ。結構へこみます。
そうだったんですね、なるほど。
コマンドラインインターフェースの考察
たぶん、これは単にマークダウンの最初にフロントマッターを入れて、そこにプレゼンテーションIDみたいなやつを入れるっていうプレリクエストのことだったと思うんですけど、
なんかこれは単に僕が自然とそうするだろうなというよりかは、僕のプレゼンテーションって基本的にマークダウンで管理してたときにフロントマッターがあったんですよ。
なので、少なくともフロントマッターを読み飛ばすことは最低限してもらいたいなっていうのはあったっていうのと、その上で、そこにプレゼンテーションID入ってたほうが、普通にコマンド履歴とかを探さなくていいから良いよなっていうふうに思ったんですよね。
ほんとそう思います。
もともとフロントマッター的なのを入れようみたいなのは思わなかったんですか。やっぱりそこはあんまりコンフィグ的なものを入れたくないみたいな考えもきっと現れたと思うんですよね。
そうですね。それで言うと、もともとコンフィグはできるだけないほうがいいと思ってました。つまり、デックコンフィグみたいのはもともとないほうがいいかなと思ってました。
とはいえ、中高さんみたいな複数のプレゼンテーションを並行してやるとか管理される方にはそういうのが欲しいらしくて、中高さんは独自でそういうような仕組みを作られていました。
で、コンフィグは作りたくないですけど、フロントマッターは私の中でコンフィグではなくて、プレゼンのステータスというかものだと思ってるんですけど、全く思いつかなかったんですよ。フロントマッターは。
なるほど。それは多分、僕がそういうマークダウンの前にフロントマッターがあるみたいなのに慣れすぎてるから、むしろ当たり前のように思ってしまっていたっていうのがありますね。僕のプレゼンツールもそうだし、このポッドキャストやってるツールもそうだし、もともとやってるブログとか、全部そのフロントマッターを入れるっていう感じになってたっていう感じなので。
何だろう、そういう自然と思いついたっていう。逆に圭一郎さん的には盲点になってたみたいな。そういうこともありますよね。
そうですね。そうやって言ってもらえるとありがたいですけど、本当に悔しかったんで。
そうですね。
これが後でピッチャポッタちゃんと思いました。
良い提案ができて良かったなと思いました。
ありがとうございます。
そうですね。もともとは多分全然説明が聞いてる人には伝わらないと思うんですけど、
deqっていうコマンドは、GoogleスライドのプレゼンテーションIDってやつと、実際にマークダウンファイルのマークダウンファイル名っていうのの2つの引数を取るっていうコマンドライン体系だったのが、
マークダウンの中にフロントマッターをつけて、そこにプレゼンテーションIDを入れられるようにすることで、引数にマークダウンだけを指定すれば良くなったという、そういうような変更ですね。
本当にこの、私はアーギュメントは必須入力が結構重要で、フラグとかオプションと呼ばれているものは、あってもなくてもいいよというような、ざっくりその切り分けをすることを好んでいて、
プレゼンテーションIDがなんか気持ち悪いってずっと思ってたんですけど、そこが難しくてですね、アーグスとフラグ、そうですね、ここら辺。
ソンムさんとか、このアーグスとかフラグの使い分けとか、どんな感じで考え、コマンドラインインターフェース全般でもいいんですけど、どんな感じで考えられてますか。
でも今おっしゃったように、アーグスっていうものは、もう必須のものだけを取る。なんなら、なくてもいい、なくてもいいというか、必要なものを取るっていうようなものになっていて、
フラグとかオプションっていうのは、最近はフラグって言われることの方が増えてきた気がしますけど、でもその名の通り、あってもなくてもいい、切り替えスイッチみたいなものでしかないんですよね。
なので、本来の考え方としては、あんまりリクワイヤードなフラグとかオプションが多くなるのはちょっとおかしくねみたいな、そういう気持ちにもなりつつも、ただある意味そういうリクワイヤードなものが多い場合は、引数の順番問題みたいなのが出てくるので、
最近はフラグとかに倒されがちなのかなっていう感じはしていますね。
なるほど。引数の順番、確かにですね。
ただ、結局そういうことが起きないように、引数の数とか順番とかフラグの数っていうのは絶対少ない方がいいっていうふうには思ってはいるんですよね。
でも、どうしても増えがちっていうところがやっぱ悩ましいなっていうのは思ってるところですね。
Unix哲学と現代の変化
その辺なんか思っていることありますか、他に。
まさにおっしゃってる感じのことがやっぱり自分の中ですごく持っていて、いろんなコマンドラインツール作ってきましたけど、
やっぱりそれぞれ使うタイミングとかシチュエーションとか、こういうタイミングだからこうであるべきみたいなのを作ることがあって、
例えば名前がすごくよくわからないツールなんですけど、シェアハットアタックっていうツールを昔作ったことがありまして、
これ何するツールかがわからないようなツールなんですけど、名前的にはそんななんですけど、
そのコマンドを叩くと、そのサーバーの中のモニタリングをしてくれて、
例えばCPUが60%以上になったときとか、メモリの使用量が何%になったときに任意のコマンドを打ってくれるみたいなツールなんですよね。
なのでサーバーで異常事態が起きているけど、そのときのモニタリングが結局ロギングが途切れていて、
次起こったときにそのときの情報を取りたいというときに、
それでいわゆるデーモンじゃなくて、プロセスとしてそのまま起動させて、
バックグラウンドで実行させて、そのままお放置しておけば何とかなるみたいなツールなんですけど、
それはそういうことを起こるときって絶対にコマンドラインは覚えてない。
Argsとかシェアハットアタックの普段使うものじゃないので覚えてないので、
インタラクティブ。コマンド1個打てば、あとはインタラクティブに効いてくれるようにしてたりとかですね。
それなりには考えてはいたんですけど、そういうことは常々考えながらコマンドラインは書いています。
そうですよね。これも多分ちょっと説明が足りない会話になっちゃったと思うんですけど、
いわゆるコマンドラインツールの中でハイフンで始まるようなものがオプションとかフラグとか言われるもので、
そういうものがなくて指定できるものをArgsっていうみたいな、そういう話ですね。
LSとかだったら引きずにディレクトリ名がに入れ付けられる。
それはArgsであって、オプションとかだったら、ハイフンヘルプとか、ハイフンバージョンとか、そういうやつっていうことですね。
こういう話をしだすと、すごくUnixという考え方っていう古い本の話に絶対なっちゃうんですよね。
ただ、これがどこまで良いかどうか、良いかっていうか現代に即しているかどうかみたいなのはすごく難しいなっていうのを思っていて、
いや、この本ね、すごく僕好きで面白い本だとは思うんですけど、背景分かった上で読むと面白いみたいな、そういう本なのかなと思ってるし、
今の人が読んでもいいんじゃないかなと思うんだけど、全てが正しいわけではないよねっていうのは思います。
それを踏まえて話していくと、やっぱり結構変わったなって思うところとしては、
Unix哲学の中で、ルールオブサイエンス、サイレンスっていうのがあるんですけど、本の中では沈黙は金、沈黙は金かなって訳されてるんですけど、異常がないとき、正しく終わったときは静かにしてろっていう、そういう話なんですよね。
それがUnixコマンドの良さなんだ、みたいなことが書いてあって、すごくわかる。わかるが、最初にUnixコマンドとか打ったときに、スルッと終わって何も反応がない、大丈夫かなみたいな、そういう気持ちも覚えているので、
今はやっぱりちょっと派手なレスポンスが返ってくるコマンドも増えてきたなっていうのは思います。
この沈黙は金をどこで覚えていたというか、聞いたかっていうのはちょっと忘れたんですけど、最近、最近って言っても最近じゃないんですけど、Goのコマンドがこれじゃないですか。
それはそっちで印象が出てますね。Goのものはだいたいあんまり喋ってくれないというか、沈黙は金で作られてるようなことをどこかで書いてたのを見たのか、誰かが言ってたのを聞いたのかっていうのは覚えてます。
たしかにそうかもしれないですね。Goは作者陣がもうUnixの開発にバリバリ関わってる人たちだから、それはそうだろうなっていう感じがしますね。だからその-Vとかをつけると、たくさん、多少は喋ってくれるけどみたいな、Goテストとかもっていうのはありますよね。
-V問題ありますよね。-V問題ないですか。なんか突然言ってますけど。
-Vってどっちに使うかって話ですか。
ログと標準出力の重要性
そうそうそうです。
バーポーズとバージョンとどっちに使うっていう。
どっちにも使われがちっていう。
使われがちですね。
しかもVって重ねられるときあるじゃないですか。
ありますね。
Vを重ねれば、VVVとかやるとどんどん饒舌になっていくっていう。バーバツって饒舌っていう意味だから。あれちょっと、ちょっと好きです僕は。
私も好きなんですけど、私の使っているGoのライブライナーとできないので、いつもいいなと思って見てます。
でも、やろうとは思わないですけどね。そこまで。
自分で実装しようとはあんまり思わないですよね。
なので、沈黙は禁とか。
あとは、例えば、本の中で例で挙げられてるときに、LSコマンドを打ったときに空のディレクトリだったら何も出力しないみたいな。
でもそれはそれでがいいんだみたいな。そういう空でしたみたいなことを言うなみたいなことが説明されてて、ふむふむなるほどねみたいなそういう気持ちになると。
でもこういうので大事なのは、ちゃんとデータは標準出力に出して、ログとかそういう対話的なメッセージは標準エラー出力に出したほうがいいよっていうのはありますよね。
そうですね。ありますし、ここいっつも悩みます。
どっち、なんで悩むかというと、しゃべってる内容が対話的なものなのか、そうじゃないのか。
例えば最近だとログはだいたい構造化ログになってきてるので、対話で出てるものも意外にパイプでつないで次に使うんじゃないかとか、
いろんなことを考えてしまって、そむさんのおっしゃってるのは多分何度かそむさんがそうおっしゃられてるのを拝見してるし、そうしたいと思いながらも、
でもいっつも毎回悩んでる気がします。ここ。
でもなんか最近思うのは、構造化ログみたいなものは特にウェブアプリケーションだったり、そうじゃない常駐プロセスみたいなものは、
そういったものが吐く構造化ログっていうのは、むしろファーストクラスな情報なので、それは標準出力に出すべきだと思うんですよね。
むしろそれは標準出力を読んで何らかのオブザーバビリティツールに投げたりとか、そういうことが求められてるので、
そういう構造化ログは標準出力に出すべきだというふうに僕は思ってますね。
でも機械が処理するべきものは標準出力に出して、人間が読むものとか、そういったものは標準エラー出力に出すべきだというふうに思っています。
でも標準エラー出力って名前なのにログをそこに吐くっていうのはちょっと直感に反しますよね。
そうですね。私は最初はもうエラーを吐くところだと思ってました。
そう思っちゃいますよね。なんかUnixコマンド、そういうの多いんですよね。
その切るコマンドは、プロセスを止めるコマンドではなくて、シグナルを送るコマンドだ、みたいなのがあったりしますしね。
あとは、Unix哲学、他にも機能は一つに絞れ、とにかく一個のことだけをちゃんとやれ、みたいなことが書いてあって。
これもよくある話で、Creeping Futurismってやつで、忍び寄る多機能主義って訳されてるんですけど、よく百得ナイフみたいなので言われる話なんですけど、
これもLSコマンドの良くない点みたいなのが書籍に書かれてて、これはすごい原理主義的な話で面白いんですけど、
LSコマンドって、ターミナルに出力させると、ちゃんと何カラムかに分割していい感じに出してくれるじゃないですか。
でも、それがダメだって書いてあって、
LSコマンドっていうのは、1行に1エントリ、1ファイルが書き出されるから良いんだっていう。
もちろん、今のLSコマンドとかって、ターミナルに出すときはそういう整形されたレイアウトだし、
パイプに渡されるとちゃんと1行1行業種交でデータが渡されるような工夫になってると思うんですけど、
多分、そういう余計な機構こそが余計なものだみたいな話をされてて、
要は、LSの結果をレイアウトして出力したいんだったら、パイプして別のレイアウト用のコマンドに渡すべきだっていう主張なんですよね。
それはね、原理主義的にはすげーわかるっていう感じがしますね。
そうですね。ログ、綺麗に。でも出しすぎると冗長なので、ちょっと整形してログというよりも、
確かパールのテスティングでタップとかは結構シンプルに出したりすると思うんですよね。
私はああいうのを見ていると、やっぱりその必要最低限だけ出して、でもあれは整形だと私は思ってるんですけど、
でもそれでもすごくいいなと思っているので、そこまで原理主義化っていうのは今聞いて、なるほどなーとか思いました。
そうなんですよね。さすがにどうかとは思うけど、主張としては面白いなっていうところがありですね。
あとは、最近変わってきてるなって思ったのは、過度な対話的インターフェースを避けるみたいな、そういうのがあって。
つまり、利用者にプロンプトさせるような、何かを聞いてきたりとか、独自シェルに入って何かをさせるみたいなのは、
自己完結しすぎだから、コマンドはちゃんと入力を受け取って出力を出すだけの存在であるべきみたいなのがあって、気持ちはわかるみたいな。
いや、すごく大事だけど、でも最近は対話的インターフェースをちゃんと用意することがユーザビリティにとっても大事だよなみたいな感じになってきてるなって思いますね。
そうですね。対話的インターフェースだけしかないツールは組み込みにくかったなっていうのを覚えてます。
アンシブルとか、パペットとかそういうものに組み込むの大変だったなっていうのは覚えてます。
たまに、イエスとかをちゃんと打ち込まないといけないコマンドとかがあって、SSHキージェンとかかな。わからないけど、いろいろあって。
そうするとなんかこう、イエスコマンドとかでパイプしてみたいな無理矢理なことをしないといけないみたいなのがありましたよね。
ありましたありました。
まあ確かにそういうのを見ると、ちゃんとフロンプトせずに、なんか打ち込ませずにもとも動くようにするっていうのが大事だなっていうのは思いますね。
そうしないとシェルスクリプトとかで使えないんで。
ケラフォンとか最近ね。
そうですね。
あとやっぱりそういう意味で、アーグスとかフラグの話とかもそうですけど、やっぱり組み合わせ爆発がすごい怖いなっていうのは僕は思っていて、
網羅すべきパターンが増えちゃうから、その式数を増やすフラグを増やすみたいになってくると、そういう意味ではあんまりその余計な機能も追加しない方がいいし、
対話とかそういうのも結構大事なところじゃないとやんないと、やっぱりテストしきれずに複雑になりすぎるっていうのはあるよなってのは思ってますね。
そうですね。それはおっしゃる通りではありながらも、私結構複雑なフラグを作りがちで。
なんで、私ちなみにやっぱり一つの機能で完結するツールなりパッケージができたときはすごく嬉しいんですけど、それができないときが結構多くて。
ユースケースは一つだが、それ以上にそこに対する要求が多いっていうときにフラグ多くなりがちで、ここをどう小さくできればいいのかなっていうのは思うことは結構ありますね。
思いますよね、それは。いやもうね、僕も最近デックに機能追加しまくりながらだからこう、うーみたいな申し訳ねーみたいな気持ちになっています。
なので、最近入れたウォッチプロセスの最適化みたいな、あれはかなり良い変更だったなと思うので、ああいうちょっとパフォーマンスだったり動作効率に効くやつも入れられてよかったなって思ってます。
ありがとうございます。
なので結構もう、僕とかも、やっぱその自分の使うツールであることっていうのが前提としてあるからOSSとしては、もうその最適なデフォルト値をまず決め打ちにするところから始めて、そこを変更したいって要望が来て、リーズナブルだったら受け付けるけど、
ちょっとメンテが複雑になりそうだなと思ったら、ちょっとごめんねっていうみたいな、そういう感じのこともあるんですよね。なので今回結構、僕はデックに対していろいろ機能を入れてもらおうとしてるんで、多分これは圭一郎さんのユースケースにないと思うんだけど、申し訳ねーけど、でもできれば入れてほしいみたいなそういう気持ちでこう、あのコミュニケーションを取っています。
機能追加の難しさ
はい、ありがとうございます。難しいですよね。
やっぱり発表資料を作る人が、今もうまっ先のユーザーなので、今私今たまたまですけど発表資料作ってないので、なかなかそこをまだまだ当事者になってないので、まだあのコード生成とか画像生成をまだ当事者になってないのでですね。
あ、そうなの?
はい、そうなんですよ。まだなので、はい。
そうだったのか。
その時を楽しみにしてる感じです。
いや、あれめっちゃ便利ですよ。
なんか、この間なんかある会社で、GOの勉強会みたいなので発表して、そこでかなりコードサンプルをお見せしたんですけど、もうめっちゃ助かりました。
だからあれで、コード生成がちょっと重くなるとか支配的になってくるというのも、やっぱり自分が今当事者じゃないので、分かってなかったので、なるほどなぁと思うことに思いました、本当に。
そうなんですよね。あれはちょっと困ってるし、まあでも一旦そうですね、なかなかよくしていこうっていう感じですね。
まあでも、やっぱりコンフィギュレーションフリーであるっていう、とにかくコンベンションオーバーコンフィギュレーションみたいな、やっぱ設定より規約っていうのはめちゃくちゃ素晴らしい言葉だと思っていて、もう設定なしに使い始められることの良さっていうのはすごいあるなっていうのは思ってるので、デッグはやっぱりそういう感じなので、そこはめっちゃいいなーっていうのは思ってます。
このコンフィギュレーションフリーの、これがデフォルトだを作るのが難しいものと難しくないものがあると思ってて、なかなかそこを綺麗にやり切ったっていうのはパッと思いつくものがないですね、今のところ自分の作ったものでは。
いやそうですよね。やっぱそこは難しいところではあるなーと思いますね。
なんか、ソムさんの今までのOSSでコンフィギュレーションフリーだからこそ良かったんじゃないのかみたいなのってパッと思いついたりできますか?
なんかあるかな。でもあんまり複雑な設定を持たせて大変になるみたいなのは少ない気がするな。
最近GitHub Actionsをいくつか作ってて、これブログにもしたんですけど、あるプライベートリポジトリからパブリックリポジトリに対してあるブランチ、あるディレクトリの内容をミラーするみたいなやつを作ったんですけど、
その時に、プッシュ先のリポジトリに対象のブランチがなかった場合に、作るっていう機能があえて削ってあるんですよねっていうのがあって。
私が今、想像では作ると思ってました。
なので同期用のブランチみたいなものを用意しておいて、そこにプッシュするっていう、そういうものだったんですけれども。
GitHub Actionsのカスタマイズ
もともとそういうカスタムGitHub Actionsがあって、僕は使ってたんですけど、それだとちょっとメンテナンスがされてないっていうのと、サインドコミットを作ってくれないっていうのがあったので、ちゃんとサインドコミット作ってくれるやつを作ったっていう感じなんですけど、
ただ、もともとのライブラリーは、ちゃんと対象ブランチがなかったら作るっていうフラグがあったんですけど、それは僕のニーズとしてはいらなかったので、落としたんですよねっていうのがあって。
それに加えて、もう一個GitHub Actionsを作って、それは単にブランチを作るだけっていうGitHub Actions、別のカスタムGitHub Actionsを作って作りましたと。
そうすれば、別にリポジトリをミラーするためのカスタムGitHub Actionsにブランチを作るっていう機能を持たせる必要がないっていう感じにしたっていうのは、最近の僕の中の面白い事例ではありますね。
まさにさっきの機能は一つに絞れの方に近い切り分け方ですね。
そうなんですよ。しかも、結果的にあるリポジトリの内容を別のリポジトリにプッシュするっていうものよりも、単にブランチを作るだけのGitHub Actionsの方がフォード行数が多くなったんですよね。
なんでかっていうと、指定した文字列がタグなのかブランチなのかハッシュなのかの切り分けをちゃんとやるのが結構難しくて、実はそういうのちゃんとやるの難しいっていうのがあるので、そういう意味では切り分けてよかったなっていうのがありました。
アクションの世界だと、その2つを合わせてコンポジットなアクションにすることも確かできたと思うので。私だったら多分、引っ付けちゃう。何も考えずに引っ付けてるだろうなと思いました。
そういう、なんかすごい僕ばっか話しちゃってるな。すいません。
今もあるかなと思うんですけど、ちゃんとそういうGitHub上でCIとかを回してくれる超便利なやつの、多分かなり最初のほうのよく使われてた、みんなが使ってたやつだと思うんですけど。
僕、トラビスすごいよかったので、ドットトラビスヤムルかな。ドットトラビスの設定ファイルをカラーファイルでもいいから置いとくだけで、もう連携してくれるみたいな感じだったと記憶してるんですよ。
そうするとちゃんとそのリポジトリが何の言語で書かれてて、ちゃんとディレクトリの構成読んで、じゃあこれはMakeTestを動かせばいいんだなとか、RubyだったらMakeTestを出せばいいんだなとか、PerlだったらProveを動かせばいいんだなっていうのを自動判別して動かしてくれるんで、それが結構いろんな言語にも対応してて、めちゃくちゃコンフィギュレーションフリーでいろんなリポジトリのテストを自動でやってくれるっていう感じだったんですよ。
今はGitHub Actionsとかいろいろ書かなきゃいけないじゃないですか、宣言的に。でも、トラビスみたいな仕組みをワークさせるのって、多分異常な複雑さを隠ぺいする努力が必要で、そういうのって難しいんだろうなっていうのは今からすると思います。
確かにですね。私もトラビスじゃないですけど、コードカバレッジのツールでOctocobっていうのを作っているんですけど、それも若干近しいことをしていて、
テスト後だったらだいたいカバレッジ.outが落ちてるだろうとか、Elcobだったらこんなファイルが落ちてるだろう、あるだろうみたいな形のデフォルトで自動判別をしまくっているコードが中に実はあって、それでなんとなくいい感じに進むようにしてます。
それはすごい大事っていうか、なんていうか尊い実装だなと思いますけど、そういったところのユーザビリティ上げることで使ってもらいやすくなるみたいなのもすごくありますからね。でもすごいこう大変なんですよね。
そうなんですよ。大変ですし、そうなんですよね。だからなんで動かないのかがわからなくなる人からすると、この時は動いてたのにこの時はなんで動かないんだってなるので、そうはあるみたいです。
最近、いろんな言語のパッケージ管理システムって、ちゃんとルートにトムルだったりとか、Rubyだったらジムスペックだったり、GoだったらGoModだったり、パッケージジェイソンだったり、そういうの置くじゃないですか。置いてちゃんと置くことが当たり前になってると思うんですけど、
こういうパッケージ管理システムの走りだったCPANとかはそういうのなかったんですよ、昔は。もうなんかターボールを、ライブラリのディレクトリをターボールに固めて投げつければよくて、そしたらサーバー上のポーズっていうシステムがあるんですけど、
それがそのターボールの中身を解析して、これはモジュール名がこれっぽいとか、このディレクトリにパッケージが配置されてるっぽいとか、そういうのをなんとなく頑張ってパースしてパッケージとして処理してくれるみたいなのがあって、すごい便利だけどよくわからない挙動になりがちみたいなのだったり。
当時はどこにメインのモジュールを置くみたいなお作法もなかったから、ルートディレクトリ直下にメインモジュールを置いてる場合もあるし、libっていうのを切ってその下に置いてるときもあるしみたいな、それもいろんなパターンを頑張って正規証言とかで網羅してパースしてみたいな、地獄みたいな行動があって、そういうのを吉田にやろうとしすぎる大変さみたいなのがあるから、
ちゃんと後発のライブラリ管理とかのシステムは、ちゃんとそういうメタ情報を何らかのファイルに書かせるみたいなのをやってるなっていうのを持っています。
なるほど。シーパンはそんな感じなんですね。
そう、シーパンはもともとそういう感じでした。僕もその頃あんまりよく知ってるわけじゃないんですけどね。
いや、それこそ、ヤムルとかジェイソンもなかった時代だから、そういうトムルとかもないし、そういうメタ情報みたいなのをどう記述するかみたいな、あんまり合意もなかったっていうのがありそうだなって思いますね。
昔はそういえばなかったんですよね。
なかったんですよ、20世紀末とか。
全く覚えてない。
覚えてないですね。覚えてないというか、でもXMLがやたらもてはやされてたのは、それこそジェイソンもヤムルもなかったからみたいなのがありますよね。
そうか、そういえばそうでしたね。
もう、ジェイソンは本当発見されたっていうのがすごい面白いですよね。
そのなんか、JavaScriptの中に書いてるこの記法ってすごくデータ構造を表すのに便利じゃねっていう、なんかそういう、それでみんなが一斉に使うようになったっていうのが面白いですよね。
面白いですよね。本当にあれはびっくりというか、すごかったと思います。
いやなんか、長く話してるけど、もう一ネタぐらいいこうかなと思うんですけど。
僕ずっとマークダウンでHTMLプラスライドに変換するっていうツールを使ってたんですけど、
これがもともと発祥が、ルーツが何かっていうと、スポークっていうツールがあるんですよ。
で、これはインギー・ドットネットさんが作ったツールで、
これはこの前もちょっとゴッシーさんの回で話した、ヤムルの作者の人ですけど、その人が作ったプレゼン生成用のパールのスイパンモジュールがあって、
多分2010年前後ぐらいはこれを使ってる人が結構いたんですよね。
それこそ最近レイヤーXに入られた猫角さんとかがよく使ってた覚えがあるんですけど。
これがもうそもそもフロントマッターがあったんですよ。
フロントマッターにメタ情報を書いて、その後にテキストでスライドを書くっていう、そういうツールだったんですよね。
基本はマークダウンじゃなくて、経由域っていうやつの基本なんですけど、中身のスライド部分は。
でもフロントマッター部分はヤムル作者が作ったものなんで、ヤムルっぽい構文に書かれていて、みたいなのがあるので。
そういうのもあるから、僕としてはめちゃくちゃスライド用のマークダウンなり、テキストファイルの冒頭にヤムルが入ってるっていうのは当たり前のことだったんですよね。
すごい。これが当たり前じゃなかったんですね。本当に。
なんか繋がってるんですね。パールのスライドツールの中でまたフロントマッターがあって、フロントマッターの中にまたヤムルがあって、ヤムルはそのヤムルの作者がまたそこにいてっていう。
そうなんですよね。なので、もうマークダウンもね、言ってしまえばパール由来の技術と言えなくもないみたいなのがありますからね。
そうなんですね。
そうなんですよ。
これもう本当に知らないです。なんかマークダウンの仕様がここ最近ちょっといざこざがあって、みたいな標準化のいざこざがあったみたいなぐらいしか知らないです。
これもジョン・グルーバーっていう方が作られたmarkdown.plっていうやつがあって、これが実装であり仕様であったっていう時代がすごく長くて。
かつ、今もちゃんとここに仕様が書かれてるんですけど、たぶんめちゃくちゃミニマムな仕様なんですよね。
だし、やっぱりそのmarkdown.plだけだと、なんというか挙動が怪しい部分があるから、いろいろそうですよね、いざこざがあって。
引用と出典の重要性
でも最近はなんだかんだで、コモンマークとかが頑張ってスペックを改善してってるなっていうのがありますよね。
でもなんか、コモンマークの仕様を最近ちょっと読んでたんですけど、実はコモンマークってあんまりミニマムなスペックなんだなっていうのを再認識しました。
もともとのマークダウン記法の振る舞いを厳格に定義してるっていうだけで、あんまり拡張記法みたいなのがないっていうことを知りました。
テーブルとかもないしね。
そうですよね。テーブルはいわゆるGFMとかGitHub Flavored Markdownで使えますみたいな認識でした。
とか、結構いろんなツールではテーブル記法使えるけど、ちょっと差異があったりとかするし、コモンマークでは定義されてないんだっていうのを改めて知りました。
もう一個ついでに話したいこととしては、ブロッククオートとか引用とかリンクとかを貼るのってすごく大事だと思ってて、
ウェブ上のテキストにおいて。で、その上で出典とか引用元を示すことってすごく大事だと思っているんですけど、そのためのサイト要素っていうのがあるんですが、
これあんまりみんな使ってないよなっていうのを思っているっていうのと、あとマークダウンでもあんまりそれを上手く表現する方法がないんですよね。
なので、それはちょっと困るなっていうふうに思ってます。
ブロッククオートはマークダウンとして使うことは結構あるなと思ってたのと、サイト要素の方はあんまり使ってる引用というか出典という意味で言うと、
ラテフを書いてた時代に意識してたぐらいで、HTMLの方であんまり書いた覚えがないのは唯一書いたとしてはてなブログかなとかいう感じですね。
たぶんブロッククオートとサイト要素の組み合わせのいい方法みたいなのが、たぶんあんまり知られてないっていうのと、たぶんあんまり決定版がないっていう感じがあるんですけど、
HTMLの構造とマークアップ
どうもはてなブログとかだとちゃんと引用、他のブログの引用みたいなのをしてくれて、それをちゃんと書いてくれるんですけど、ブロッククオートの要素の中にサイト要素が入るようになってるんですけど、
なんかどうもそれはバリットではないらしいみたいなのがあって、要はフィールドセットでくくって、ブロック要素の外に、同じフィールドセットの中にサイト要素を書くみたいなのが本当は望ましいらしいみたいなのを最近見たんですけど、それもどこまで本当なのかわからないみたいなのがハリミツさん。
難しいですよね、このHTMLも。
いや、HTMLね、難しいんですよねっていうのと、僕の時代のこういうHTML中みたいな人たちは、この情報構造をどういうふうにマークアップすべきかみたいな話を結構活発にやってたと思うんですけど、最近全然そういう話がないなって思ってて、
なんかそういうのは終わってしまったのかみたいな、なんかちょっと時代が変わったんだろうなっていう気持ちではありますね。
なるほど。なんかその構造化、HTMLも構造化されてるよねっていうところで言うと、確かに私は多分最初はですね、テーブルデザインから入ってるので、テーブルデザインがあり、その後にいやそんなんじゃダメだっていう時代があり、
で、GIFがもてはされる時代がありっていう感じだったので、最近よく見るその構造化とかしっかりしましょうっていう分野で言うと、アクセサビリティの分野の方たちはやっぱりかなり今でもすごく意識されてるし、っていうのはやっぱりよく見ます。
そうですよね。
そういう点でもやっぱり。
そこはすごく、そういう意味でもやっぱり正しいマークアップみたいなのは大事だし、あとは、そうですよね、よく言われる話で、やっぱりウェイアリアとかを適切に入れていくことは大事なんだけど、そもそものHTML要素としてそれが含意されてるのであれば、もうそんなベタベタと余計なアトリビュートを増やさなくていいよねっていうのはあるので、
でもそういう議論が結構あんまり伝わってないみたいなのも見たりするから、ちょっと大変そうだなって思ったりはしますね。
そうですね、どんどんリッチになってますからね、画面は。
でもちゃんとアクセシビリティみたいなところはすごく向上はしてきてるみたいで、いいことだなっていうのは思いますね。ちゃんとその読み上げのスクリーンリーダーとかも機能するようなサイトがすごくやっぱり今は多いみたいですしね。
なんか普通にその目の見えないプログラマーの方とかも活躍されたりとかしてるので、そこはすごい良いなっていうのは思ったりはしています。
最近HTML書いてないな。
書かないですよね。僕はちょいちょい自分のサイトとか、それこそマークダウン書くときにこだわっちゃったりとか、そういうのがある感じではあるんですけど。
なので、こういうHTMLマークダウン厄介オタクみたいな人に絡まれて、けい一郎さん最近大変だなって思っています。
ありがとうございます。
そういう感じで、前半だいぶ僕の方が興奮して話してしまいましたが、一旦この辺で切りますか。ということで、一旦切ります。ありがとうございます。
ありがとうございます。
