00:00
ちょっと片渕さん、聞いて欲しいんですけど、最近ちょっと不便だなーって感じることがあったら、すぐにクロードコードとか使って簡単なCLIツールとか作っちゃったりしてるんですよね。
CLIとかだったらUIとか用意する必要ないし、結構手軽に作れたりするんで、楽だったりするんですよね。
そうですね。結構自分もなんかやるんですよね。コードエックスとかクロードコードに言うと結構出てくるし、
やっぱ最近は本当に以前はなんか微妙に動かないとかあったけど、最近は本当に動くから結構やっちゃうし、
自分も結構アイディアさえあれば作れたな、作れるなっていう感じで作っちゃってますね。
自分特に語言語好きなんで、語でばっか使ってるんですけど、語だとポンって前代に何か置くだけで作れちゃうから、
いろいろと動いちゃうんですごい便利ですね。
確かに片渕さん結構そういうツール作ってるなーみたいな印象、なんとなくな印象があるんですけど、今までどんなの作ってきたんですか?
いくつかあるんですけど、なんか昔から作ってるやつはNotify Slackってやつで、コマンドラインから気軽にスラックに色々通知したりできるやつとかもあるし、
あと大量の、ファイルが例えば数万とか入ってるディレクトリってLSすると結構固まったりするんですけど、そういうのが固まらずにガーって出せちゃうみたいな、
LLSってやつ作ったりとか、あと最近だとソースコードの改ざんを検知するツールで結界っていうのがあって、
この結界とかはもう完全にAIを使って作ったツールだったりしますね。
結構作ってますね。なんかその中でも、今まで作った中でも一番ギターのスターあるみたいなのって何だったりするんですか?
それが、2024年に作ったPerlっていうテキスト処理のツールで、結構これはね、自分もスター詰まって良かったなと思ってるやつですね。
いいですね、Perl。本当に似たような言語の名前を知ってるんですけど、そのPerlは別の、プログラミングは別のPerlというツールですね。
じゃあ今日そのPerlについてちょっとお聞きしたいなと思ってるんで、いいですかね、今日はそこ聞いて。
はい。
じゃあちょっとPerlなんですけど、これ一言で言うとどういうツールですか?
一言で言うと、正規表現をシェルスクリプトで使えますっていうツールですね。
もうシンプルイズベスト。
そうですね、もうシンプルです。
なんか作った背景みたいなのあるんですかね。なんかなんとなく今の聞いた感じだと、いろんなツールもすでにあるんじゃないと思うんですよね。
例えばSEDOだったりとか、あるんじゃない?
そうですね。まさにSEDOもそうなんですよ。SEDOと似た感じなんですけど、SEDOってなんか意外と知られてないんですけど、
MacはBSD版で、Linuxがグミ版で、微妙に挙動が違って結構基本的なやつも大体動かないんですよね。
03:05
片方でしか動かないっていうものばっかで、基本的に動かない。両方で動くものって基本的に書けないんですよ。
そんなに差がある。結構差がある。
結構差がありますね。
なんか具体的な例とかあったりします?言葉で表現しづらいかもしれないですけど。
正直SEDOあんま使わないんで覚えてないんですけど、なんか自分の経験として、なんか会社の開発環境を構築しようとしたら、なんか自分だけ動かないっていうのがあったんですよ。
で調べたら、自分のMacって結構Linux用のグミのコマンドに入れ替えてたりするんですよね。いろんなコマンドを。
意外。
GSEDO、GNUのSEDOにしてたんですよ。そしたら動かなくて、これMacでしか構築できないじゃんみたいな話をして、
結局僕がSEDOのバージョンによって、GNUかBSDかによって挙動を分ける部分を追加して、自分の手元でも動いたみたいな経験があって。
いやなんか正直何も考えずにやっちゃうとSEDO使っちゃうし、そうするとMacでしか動かないような開発環境が結構気軽にできちゃうなっていうのが実体験としてあったんですよね。
じゃあチームの中でもともと共有されてたコマンドが動かなかったっていうのが一番背景としてある?
それが結構大きい背景としてあって、結構その前からSEDOがLinuxとMacで挙動違うからっていう理由であんまり使わないようにしたんですよね。
元から知ってた。知ってて、その上でっていう。
元々知ってたから自分のMacをGNU SEDOにしてたんだけど、なんかそういうことがあって、自分だけGNU SEDOにしてもそういうことが起こるから、
そもそも良くないなっていうのもあったし、で自分はそういうMacとLinux両方使うんで、MacとLinuxで挙動違うコマンドって使いたくないんですよね、そもそも。
まあわかりやすくそうだよね。
そうね。なんで、元々プログラミング言語の方のPerlをよく使ってたんですよ。Perlでワンライナー結構書けるんで、
そういうその正規表現で、例えばGitGrepしたやつを書き換えたりとかっていうのでよく使ってたんですよ、元々。
けど最近Perlって入ってないんですよね。Macも新しいやつだと入ってないし、LinuxもUbuntuは確か入ってるんだけど、
Red Hat系のミニマムのRed Hat系とかでもミニマムだと入ってないし、あと最近ってもうみんなDocker系でしかLinux使ってないんで、
Dockerコンテナーだと絶対入ってないんですよね。
最小構成にしてしまってると絶対に入ってないってこと。
絶対に入ってないんで、だからもう以前みたいにPerl入ってるよねみたいな感じじゃもうないんですよね、特に。
そうなるとみんなどうするんだろうなって思ってて、いろんな人に実は聞いてたんですよ、これみんなどうしてるんですかねみたいな聞いてて、
06:07
みんなどうにもなんないのではみたいな反応が多かったんですよ。
諦めみたいな。
普通にBSD版の制度使えばいいんじゃないみたいな、そういう感じだった。
なんかみんな諦めてるような印象を自分は受けましたがね。
どう思ってるんだろう、よくわかんない。
そういった背景でPerl、今回のPerlのツールを作ろうとして動いたっていうところなんですかね。
そうなんですよね。
MacとLinuxで同じように使えるってところが一番の肝ってところ。
一番の肝で、あとインストールも簡単、そのGoのバイナリーを持ってくるだけで使えるので、もうバイナリー持ってくればもうどこでも使えるよっていうのがすごい売りですかね。
いいっすね。そんなPerlなんですけど、プログラミング言語との言語の方のPerl、同じ発音というか若干イントネーションが違うのかな。
若干イントネーション違うんですよね。
PerlとPerl。
ちょっと違うんだけど、同音異義語みたいな感じになってるかなと思うんですけど、そのプログラミング言語とのPerlとの関係性みたいなのあったりするんですか。
全くなくて、ただ一応Goの正規表現ってPCREの正規表現で、PCREってPerl互換の正規表現なんで、使えるのはPerlの正規表現と基本的には同じにはなるんですよね。
けど名前は別に全然関係がなくて、もともと川のせせらぎみたいな意味らしくて、この辺はGPTと相談して文字列を色々いじったりとかするので、そういう川のせせらぎみたいな綺麗さに惹かれてこの名前にしたっていうのが大きいです。
いいね。なんかすごい川のせせらぎって聞くとすごく綺麗なイメージがあるね。清潔感があるというか。流れるようなっていうようなイメージ。
流れるようなみたいなのをイメージしてて、その辺もReadMeに書いてあるんだけど、ログをガーって、例えばTLFとかでログガーって流して、それに対してグレップの代わりみたいなこともできるようになってるんですよね。
なので、そういうのやるとまさに流れるような感じで使えるし、グレップみたいに使えるので色つけるみたいなこともできる。
なるほど。
ヒットしたやつに色つけてくれるっていう機能があります。グレップみたいに使った場合はですけどね。
エラーの部分を赤にするとか。
そういうのもできます。
具体的には。すごい便利そうです。
なんか入力モードでLINEモードとファイルの一括モードがあるかなっていうのがReadMeとかに書いてあるかなと思うんですけど、そこら辺とかのやつはアクセスログとか大量のストリーム入力に対応したいからLINEモードとかを対応したみたいな背景あったりするんですか?
09:08
そうなんですよ。これ結構作るとき悩んで、なんか正直今まで深く考えたことがなかったんですけど、
例えばその今言ったテール-Fでパイプしてグレップみたいに使うっていう時と、あとそのファイル、例えばそのGitGrepでファイル持ってきて、そのファイルの中で例えばこの特定の文字列書き換えるとか、そういうのって実は処理としては全然違うんですよね。
なんか普段多分考えずに打っちゃうんだけど、そのアクセスログとかだと1行ずつで処理を実行しないといけなくて、
なんでかっていうと、その一気に全部ファイルもらってからやろうとすると、テール-Fとかでパイプしてると永遠に終わんないんでファイルが。だから永遠に何も出ないようになっちゃうんですよ。
なるほど、じゃあファイルの末尾が来ないから。 そう、末尾来ないから永遠に何も出ない。
なるほど。 だから1行ずつで処理しないといけないんですよ、そのケースは。
けど、ファイルに対して1行ずつで処理しちゃうと、その例えば前の行でこうだったら次の行でこうしたいみたいな処理がかけないんですよね、今度は。
そうなので、これって処理根本的に分けないと無理っていうことに実装してて気づいたんですよ。
その同じようなことをやるんだけど、そもそもの入り口が違うから実装が違くなってくるよねっていうようなお話。
そんな感じですかね。なんかそもそもこれもやっぱり実装しないと気づかなかったんですよね。
あ、これって全然違うじゃんっていう。
あの言われたら、まあそれはそうだよなという気がするんだけども、その前だったらちょっと分かりづらいよねっていうところが、こういう系の実装に関しては確かに。
そうですね、だから、あ、そうかこうなるの、自分で実装するとこうなるのかっていう学びが結構ありましたね。
今まで出てきたお話の中で出てきたグレップっていうのも出てきたかなと思うんですけど、グレップとの立ち位置の違いみたいなのあったりするんですか、このパール。
グレップもその正規表現の特徴なんですよね。そのパールが出てくる前に作られた正規表現なんで、パールが出てくる前って書くツールとか言語でなんか方言がすごいたくさんあったんですよね、もともと正規表現。
で、パールが出てきて、プロミュニティ言語のパールの正規表現がすごい使いやすいっていうので、みんなPCREのパール互換の正規表現ばっかり実装し始めたんですよね。
おー、なるほど。
なんか我々からすると、なんか別にパールの正規表現って、なんかそんな画期的かって言われると微妙だと思うんですよね。
けどそれってパールが出てきた時って、パールの正規表現が画期的だったからみんながパクった結果、今はパールの正規表現以外みんな知らないってなってるんですよね。
なるほど。すごいなんかいい話だなと思いますね。今だったら当たり前の正規表現のフォーマットがパールによって、プログラミング言語のパールによって統一されたという話。
12:05
そうなんですよね。で、グレップとかはその前に作られたやつだから違うんですよね、文法が。
なるほど、すごい理解できました。じゃああれですかね、他のちょっと例を出すと、マークダウンみたいな感じですかね。
マークダウンもGitHubが出てきて、GitHubマークダウンが事実上の標準になったみたいな、あれある気がするかもしれないですね。
当時はホロウィブポケットがたくさんありましたからね。
なんかそういうのにちょっと似てる感じがしますね。なんかこう便利なやつがドンと出てきたらそれにみんな業界が合わせていくみたいな。
パールでもとスタンダードになっていったんで、だから今から見るとパールの何が先進的だったのか正直分かりにくいと思うんですけど、実は今我々が当たり前だと思ってるやつが当時は当たり前じゃなかったっていう。
で、それにその例に倣ってGoの正規表現もパール互換のものが使われてる。
そうですね。Goもパール互換の正規表現です。
ちなみにRubyとかの正規表現も互換性ある?
Ruby、HPもパール互換の正規表現ですよ。
なるほど。じゃあ今の主要なプログラミング言語の正規表現はまあだいたいパール互換なんじゃないか。
そうですね。JavaScriptもパール互換なんで、基本もう我々が普段見る言語は全部パール互換ですね。
じゃあなんかもう正規表現って言ったらもうほぼほぼじゃあもうパールになっていて、
で、その中でGrepとかがまあ前のツールがちょっとまだ違うフォーマットが残ってしまってるっていうのがあるんですね。
そうですね。SQLとかどうなんすかね。ちなみにすごい脱線するんですけど。
SQLは一応SQL標準とかありますけどね。なんか微妙に、微妙に。
若干違うよね。
基本的にはざっくりは一緒だけど微妙に違ったりしますね。
そこら辺のイライラ度合いすごいんですよね。かなり。こっちだとこれ使えた、こっちだとこれ使えないっていうのがすごくちょっとあるっていう。やっぱ正規表現の難しいところ。
正規表現もパールでしか使えない正規表現とかもあるはあるんで、完全に全く一緒ってわけじゃないけど、まあなんか我々が普段使うような主要な書き方は基本全部一緒っすね。
いいですね。ちょっとパール、ツールの方の正規表現の方のパールの方に話し戻すと、今回のこのツールに関してはGoの正規表現をそのまま使うような形になってるから、まあそのまま使いますよっていうお話かなと思うんですけど、なんかここら辺の設計思想みたいなのあったりするんですかね。
設計思想としてはなんですかね、Goのレグイエックスピンそのまま渡しているだけではあって、ただそのオプションは極力明示的にしたつもりですね。
フィルターしたいんだったらフィルターって渡せばいいし、除去したいんだったらエクスクルードって書けばいいし、あとなんかちょっと変、なんか変わってるのはフィルターを複数渡したりして、
15:07
フィルターを複数渡すとオア条件になるんですよね。どっちかにヒットしたらヒットするみたいなのになるって機能があって、
アンドでやりたいんだったら普通にパイプすればいいんで、パイプでパールを呼べばいいんで、フィルターで複数渡した場合はオアになります。
こっちがオア、こっちがアンドってどう決めました?
それはそのアンドだったらパイプするなって思ったんで、オアだったらやる方法がないんですよ。オアの積表現書けばいいんだけど結構めんどくさいじゃないですか、それって。
確かにパイプでオアが表現できないんですね、普通に考えたら。渡ってこないから。
そうです。
なるほど、だからオプションでオアをサポートしたというと。
そうですね。
かなり合理的ですね、確かに。ちなみにソースコードとかちょっと見させてもらって、ちょっと見たんですけど、ちょっと気になったところで、
これが意図的かどうかわかんないですけど、依存を極力少なくしてるのかなというのを感じたんですけど、そこら辺なんかあったりします?こだわりみたいな。
基本自分はGoの標準パッケージが好きなんで、オプションを受け取るのもGoの標準パッケージのフラグしか普段自分使ってないし、
なので基本的には極力外部のパッケージには依存しないような形で作ってるはずですね。
だからそこら辺も結構ね、外部依存してしまうとやっぱり、最近だと大井先生のセキュリティーシューとか結構発生しがちかなと思うんだけど、
そこら辺のリスクも回避できるし、あと単純にぶっ壊れないっていうのもあるかなと思ってて、
やっぱり標準パッケージをできる限り使うみたいなのは結構重要視してるっていう、好きだからみたいなところかな。
重要視してるし、単純に好きなんで、Goの標準パッケージが好きなんで、基本Goの標準パッケージあるんだったら標準パッケージ使うよねって思ってる派ですね。
てか、だいたい標準パッケージでこと足りるっていう意味でもある。
Goはね、標準パッケージでだいたいこと足りる、これは無理みたいなのは、あとこれはすごい使いにくいとかはもちろんあるんだけど、
ただPowerについては外部にリクエスト飛ばさないので、そもそも構成的に、そんなに必要はないって感じですね。
かなりミニマムなツールだからみたいないうところもありけりと。
正規表現が使えるだけだから、外部にリクエストも飛ばさないし、特に依存は必要なかったっていうのが大きいですね。
いいですね。本当にミニマムなツール、本当にそれだけができるようなツールっていうのはそれだけで価値があるかな、個人的には思ってて。
かなりシンプルなツールの方が強いかなと思ってて、それが体現できてるツール、勝手な評価だけども、それが体現できてるすごいツールなのかなってちょっと思いましたね、感想ですけど。
18:09
ちなみに、導入のしやすさみたいなのも結構こだわってるのかなと思って、その単一バイナリー、単純にバイナリーをダウンロードしてきて、パスが通っているところに置いておけばいいよねみたいなところもあったり、
あとはGitHubのReadMeに動画載せてて、利用イメージ結構わかりやすくしてくれてるのかなっていうのがあるんですけど、
そこらへん、どうなんですかね、こだわりで動画載せてたりするんですか?
そうですね、GitHubのReadMeに、流れるところにパイプするとこんな風に使えるよみたいなのを出したくて、
あとやっぱりGitHubのスターをある程度集めたいなと思った時に、そういう動画がないとスターつけてもらえないかなと思ったので、
結構ね、そこはこだわりましたね。この手のツールってやっぱりある程度スター集めないとあんま使われないなと思っていたので、
やっぱりそこはスターが集まりやすいような形っていうのは考えてやった感じですね。
すごい。信頼値はね、結局GitHubのこのリポジタリアはこんだけスター集まってるから、信頼できるからちょっと使ってみようかなみたいなところがあるから、
ってことですかね。
そのスターを集めるみたいなの、最初どうでした?リリースして、ハッカーニュースとか、あとはZENの記事とか書いてるの見たんですけど、
最初から結構スターつきました?
いや正直、最初ZENで日本語の記事出して、確か数個はついたのかな。
で、けどそんなほんと数個ぐらいっていう記憶してますと。
で、ハッカーニュースに投稿してみたら、もっとつかないかなと思ってハッカーニュース投稿してみたら、結構ついて100超えてみたいな、で今のスター数になってるって感じですね。
今240ぐらいですかね。
そんぐらいですかね。
232ですね、現時点で。
じゃあやっぱハッカーニュースが強いっていう、単純に。
ハッカーニュースもそうだし、やっぱその英語圏の人の方が人数も多いし、あと気軽にスターしてくる感じですね。
日本人はそんなスターつけてこないっていう経験促上。
すごいなんか、いい発見、いい知見ですね、それ単純に。
やっぱり英語圏に対してアプローチしていかないと、こういうOSSみたいなツールっていうのはどんどん広まっていかないっていう意味でもあると思ってて。
そこは結構意識してて、だからさっきの動画用意したのも結構もうハッカーニュース狙いではあったんですよね。
ハッカーニュースで来た人にスターつけてもらうにはどうしたらいいかなと思って動画を貼っておいたっていう感じですね。
21:00
もうあれですよ、英語で書いてても文字読まないですからね。
結局これどうなってんのってなる。
動作イメージちょっとつかめないと、そもそも入れないしねってダウンロードしないしねってあります。
そうなんですよね。このツールって正直バズるかよく分かんなかったんですよね。
正直さっきも言った通り、他の人と話しても別に困ってる人自分だけなのかなっていうのがあって、
絶対困るはず、絶対みんな困ってると思うんだけど困ってる人自分しかいないのかなっていう何か疑念というかがあって、
で、ハッカーニュース投稿してみたら結構バズって、やっぱみんなこれ困ってたんだっていう何か安心感というか、
やっぱりこれみんなペインだと思ってたんだなっていうのがありましたね。
すごい、いいですね。かなり理想的なOSSみたいな感じですけど。
使ってる人のコメントとかって何かどっかで見たりしました?
見ないですね。どんぐらい使われてるかも自分はよく分かってない。自分は結構使ってるんですけど。
230スターあるようなOSSのツールでもやっぱりその利用動向みたいなような、やっぱなかなか見えづらいっていうのがあるんですね。
見えづらいし、あと特にパールって何かワンライナーとかで適当に書いて動いたら終わりっていうケースが、まあ自分自身が使ってても大体そうなので。
まあ確かに。基本的には使い捨てだからみたいなのがあるんですかね。
手元で軽くやるとか、あと自分は結構GitHub Actionsでちょっとファイル書き換えるとか、あとシェルスクリプトで正規表現使いたいとか、
なんかそういうので使ってるけどっていう感じですね。
なんか単純に、そういう利用を誰かが他の人が使ってくれてるみたいないうのが見えてないと結構モチベーション維持みたいなのって本当なく難しそうかなと思うんですけど、
そこら辺は問題ないですかね、その計測的に。
現状だと自分が使ってるのでそんなにないですかね。使ってくれたら嬉しいけどっていうぐらいですね。
やっぱり自分が一番のユーザーだから、もちろん今後もサポートというかメンテナンスしていくし、使いづらいところがあったら積極的に直していくしっていうのが元々のモチベーションとして、すごい強いモチベーションとしてあるっていう。
自分がなんか使ってて変だなと思ったら実際に直してるし、まあそうですね、それはやる、今後も多分やる。自分自身がユーザーなんでやるだろうなって感じですね。
いいですね。やっぱりそういう自分が使わないと、使うようなツールじゃないとね、なかなか難しいですよね。改善していく。
どんどん使い続けて、ドックフーディングして、改善していくっていうのはなかなかやりづらいですよね、やっぱり。
24:02
そう、やっぱりなんかそのある程度熱意がないとこの手のツールってやっぱり完成してないし、
あと結局本当に使ってないと、何て言うんですか、なんか芯を食ったような感じにならないんですよね、自分の感覚だと。
いや、マジで真理だと思いますね、そこに関しては。
なんか使ってても、あれこれ本当にこういう人たち使ってるのかみたいなツール正直あるので、
なんかそれだとやっぱり他の人が使ってくれるようにならないんじゃないかなと思ってますね。
いいですね。ちなみに片杉さん一関とかも結構運営だったり、あとは一人参加してるだったりとか、
いろいろ関わってるかなと思うんですけど、イスコンとかで使われるような場面とかって結構あったりするんですかね。
自分がイスコン出るときは一応入れてたのかな、なんか一応入れようとしてるんだけど、別になんか使ったり使わなかったりって感じですね。
まあ用途によってっていうか、本当に。
別にグリップは使うんで、別に力表現使わないならグリップの方が早いし、別にグリップ使うんですよね。
で、グリップでもっと複雑なことやりたいときにパウダー使うんで、そういうもっと複雑なのを見たいときじゃないと使わないし。
なるほど。じゃあなんかパッと見るっていうのだったらグリップの方がいいしっていうような。
そうですね。
本当にあの単一の文字です。例えばエラーとかだけだったらグリップの方が早いよねって。
グリップの方が楽じゃないかなと思いますね。
単純に。
まあできますけど。で、同じことはできるんだけど、正規表現使わないんだったらどっちも変わんないんでっていう感じですね。
最初からインストールされてるしねっていうのがありそう。
まあそう、それも大きい。
グリップに関しては。確かに。
ISCOの場合はそういう複雑な条件で検索するみたいなのがあまりない可能性が。
あんまりない。ソースコードがあんまり大きくないし、あんまりない気がしますね。
確かにそういうのがありそう。
自分が以前その似たようなことをやったのはあれですね、そのHTTPS化をやるときにHTTPからHTPSに置換しないといけない。
っていうときに当時プログラミング用語のパウルを使って、ワンライナーを使って結構置換したんですよ。
GitGrepと組み合わせて。
で、そういうのはそれに近いことをたまにやりたいことあるので、そういうときはパウルを使うんですよね。
自分の作ったやつを使ってGitGrepとパウルを組み合わせて、どんどん置換していくっていうのはたまにありますね。
なるほど。じゃあかなり大規模な置換みたいなのがやりやすいというと。
そういうのを要想定して作ったツールではある。
あと実はextractっていう機能もあって、このファイルの中の特定の文字列だけ抜き出したいみたいなやつもあるんですよ。
で、そういうのもたまに使いますね。
それはどういう用途で、どういうユースケースで。
このファイルのこの文字列を抜き出して、でそれを他のCLIに渡すとか。
27:04
パイプでね。
パイプとか、あとなんだっけ、なんかシンクオートみたいなやつで渡すとか。
具体的に何を抽出して、どういうワンライナーで使ったの?
なんだっけな、なんかパッと出てこない。
覚えてる、そのときそうやったってだけだから。
このファイルのこの文字列だけ取っていきたいとか、この行のこの文字だけ取っていきたいとかがたまにあって。
そのときに使ったっていう。
そのときに使うように作って、実際自分もたまに使うって感じです。
ちなみに、今までの話全部、自分でコマンドを叩いてっていうようなところかなと思うんですけど、
AIから使う、例えばクロードコードからコマンド実行してもらう、GHコマンドとか自分の場合は結構実行してもらったりするんだけど、
そういう文脈でこのパール使うみたいなのはどうなんですかね、あったりするんですかね。
クロードコードとかってなんだっけ、PTだっけな、なんかそのグレップ、すごい速いグレップみたいなのがそもそも内行されてたりするんです。
あるんだ。
みんなの手元に入ってるんですよ、実は。
クロードコード入れると勝手に入るんですよ。
で、なんかそれでAIって基本的にやってるので、パール使いたいケースはたぶんないんですけど、
ただ、つい先日、GitHub Actionsだったかな、でパール使えないやつ、コードXに実装してもらったんですけど、
全然なんかパール使ってって言ったら、コードXで検索してきて、で使い方調べて、で自分で正規表現を実装してってのを勝手に全部やってくれたんで、
実装とかは全然やってくれますね。
すごい。じゃあちゃんとできたんですね。リードミーを読み込んで、
読み込んで、正規表現渡せばいいんだ、みたいなのを理解してくれて、全部実装してくれましたね。
いやなんかそこら辺も、あれですよね、そのLLMが理解しやすいというか、まあおそらくなんですけど、そのLLMが理解しやすいイコール人間が理解しやすいだと思ってて、
そのぐらいシンプルになってるから、割とサクッと導入できたみたいなのありそうですよね。
そうですね、だいぶめちゃくちゃシンプルだし、明確なんで、そもそも人間が分かりやすいように作ってるんで、明確なんですよね。
AI時代もそこら辺めちゃくちゃ重要だなと思ってて、そもそも人間が分かりやすい、イコールLLMが分かりやすいと思うんだね。
そうですね、そもそもこれ専用で作ったツールなんで、それはもう明確なオプション名だよねっていう、それだけではあるけどって感じですね。
ちなみにこれからこのパールを使ってみたいな、みたいな人に向けて、なんかここら辺で使うといいよだったりとか、こういう感じでチームの方に導入していくといいよみたいなメッセージあったりします?
30:06
そうですね、普通に正規表現かけるだけなんで、なんかCLIツールで正規表現使いたいとか、あとシェルスクリプトで正規表現使いたいとか、今でも全然あると思うんですよね。
そういう時にこういうツールがあるって知ってると、一気に楽になると思うんで、あとなんか結構あるあるなのが、グレップとか他のツール使って正規表現間違ってるとか、そういう事故結構自分見たことあるんですよ。
やっぱりそういう使い慣れた正規表現じゃないと結構事故も普通に起こるんで、そういう事故防止っていう観点でも結構いいんじゃないかなとは思ってますね。
事故防止みたいなとこちょっともうちょっとだけ深掘って聞きたいですね。単純に間違えていたっていうような話なんですかね。
そうですよ、単純に正規表現間違えていた。結局グレップの正規表現ってパールの五感じゃないからみんなわかんないですよね、書き方。
雰囲気で。
雰囲気で書いちゃうと絶対想定と違う動きするんですよ。なので普通に事故が起こり得るので、やめたほうがいいと。自分はやめたほうがいいと思ってますね。
すごいわかりやすい例出すと、GitHub Actionsとかでそういうグレップとかを使って間違った正規表現を書いてしまったが故に、本来であればリリースされないものがリリースされてしまったとか、そういうのもあり得るわけ。
あり得ますね。そんな重要なところじゃなかったんですけど、実際自分の社内でもグレップの正規表現間違って事故ってたんで、それは自分がもうパール使って直したりとかしましたね。
すごいわかりやすいユースケースかなと思います。ありがとうございます。じゃあちょっとかなり今回はパールについて深掘って聞けたかなと思うんですけど、なんか最後にメッセージあります?
そうですね。普通に自分はよく使ってて、使いやすいんで、例えばなんかソースコードが、ここのソースコードが変更されていたらこのファイルのここを書き換えますとか、なんかそういうのとか使ったりとか、
あと変更されたファイルのリスト見て、ここが変更されてなかったら特定のラベルつけるとか、なんか本当に色々なシェルスクリプトで正規表現使いたいとか、
なんかここの処理だけちょっと軽く正規表現でファイル書き換えたいとか、本当にいろんな用途で使えるので、なんか気軽に使ってみてほしいなと思っています。
ありがとうございます。
じゃあもうちょうどいい時間になりましたので、今回はここまでにしたいと思います。
突然始まったヤオヨロズのOSSですけど、この番組では毎回一つのOSSを取り上げて、それについて片辻さんとヘンテコで技術的なところも深掘りしながらお話をしていくような番組です。
33:04
今後もその名の通りヤオヨロズのOSSを取り上げていきたいなと思っておりますので、ぜひお聞きのプラットフォームでフォローと高評価の方をお願いします。
またこのOSSについても取り上げてほしいなどありましたら、コメントやXなどで教えていただけると嬉しいです。
番組についての感想もお待ちしております。
Xなどでつぶやく際にはハッシュタグをヤオヨロズのOSS、ヤオヨロズは漢字でのOSSをつけてください。
それでは今回ありがとうございました。
ありがとうございました。
