sachaos さんをゲストにお呼びしました。彼が開発しているオープンソースソフトウェアの viddy を Golang から Rust で全面的に書き換え、version 1.0.0 をリリースしたとのことで、その開発秘話について話しました。また収録前半では、彼が最近購入した Tesla の車についてもお話を伺いました。
ご感想はご意見は X でハッシュタグ #LondonTechTalk をつけてつぶやいてください。お便りはこちらの Google Form でも募集しています。
Summary
今回のエピソードでは、坂尾さんが開発したオープンソースプロジェクトViddyのGoからRustへの移行について詳しく説明されています。また、坂尾さんのテスラに関する体験やその特徴についても語られています。Viddyのリリースに至るGoからRustへの移行プロセスが詳細に語られ、坂尾さんは自らの経験を通じてRustへの挑戦やコミュニティとの関わりを振り返り、オープンソース開発の楽しさについても触れています。ポッドキャストでは、ViddyのリリースとGoからRustへの移行に関する議論が行われ、機能追加やコマンド実行結果の履歴保存、コミュニティからの要望への対応についても触れられています。Viddyのバージョン1.0.0のリリースに伴い、GoからRustへの移行の詳細が語られ、特にANSIコードやDiff機能の実装に関する技術的な挑戦が共有されています。開発者たちの努力により、ユーザーが求める良好なUIとUXが実現されていることが強調されています。
Viddyの移行
Speaker 1
London Tech Talk リスナーの皆さま、こんにちは。
Kazuです。Kenさん、今日はよろしくお願いします。
Speaker 3
はい、よろしくお願いします。
Speaker 1
今日はゲストに坂尾さんをご招待しています。
坂尾さん、よろしくお願いします。
Speaker 2
はい、よろしくお願いします。
Speaker 1
本日はですね、坂尾さんが先日、
彼が開発しているViddyというオープンソースのですね、
Goでボトボト書かれてたんですけど、それをRustにいって書き換えたということで、
そのお話を聞いていこうかなと思っています。
が、最初にちょっと私、個人的に気になっていることがありまして、
坂尾さん、先日テスラの車を買った後、Twitterで報告されていまして、
乗り心地とかいろいろ聞いてみたいなと思うんですけど。
Speaker 3
すごい、おめでとうございます。
Speaker 2
ありがとうございます。
Speaker 1
おめでとうございます。
Speaker 2
そうですね、乗り心地。
僕、前提として車、初心者で1代目なんですけど、
10何年くらいペーパードライバーやってて、
今年の初めにお父さんに車の運転方法を教わり、
前から欲しかった車、テスラをちょっと買いましたと。
そうですね、乗り心地はやっぱりスムーズですね。
他の車をあんまり知らないから、比較とかはあまりできないんですけど、
スムーズに動くなって感じですね。
ワンペダルドライブってご存知ですかね?
ワンペダルドライブ、何ですか?
普通の、例えばオートマの車とかだったら、
まずドライブにすると勝手に進むじゃないですか。
クリープ現象って言ったかな。
勝手に進むから、それをブレーキ踏んで止めて、
徐々に離してゆっくり進めて、
アクセル踏んでグッと進んでいくみたいな形だと思うんですけど、
EVなのかな?テスラのワンペダルドライブだと、
基本的に何も触ってない状態だったら、
ドライブに入れてても動かないんですよね。
なるほどね。
アクセルを緩やかに踏んでいくと、
アクセルの傾きでもスムーズに進んでいくっていう形になってます。
さらに、感性もあんまり効かないんですよね。
快性ブレーキって言って、アクセルを離すじゃないですか。
普通の車だったら感性で結構進むんですけど、
アクセルを外すとブレーキがかかって、
その動力を殺して電力に変換してるらしいんですよね。
だから、その動力を殺して電力に変換することによって、
高速距離が伸びることができたりするという形で、
だからアクセルを離すと、
ブレーキ踏んだ感じで止まるっていう感じになってて、
その辺は最初慣れるのめちゃくちゃ苦労したんですけど、
1日2日とか乗ってれば慣れた感じでしたね。
そういう感じで、他の車と乗り心地っていう意味でも結構違うところはあるし、
結構面白い車だなって思います。
Speaker 3
めっちゃ面白い。乗り心地すごい良さそうですね。聞いてるだけで。
Speaker 2
そうですね。スムーズに本当に。
多分、音もなく本当に今進んでいくんで、
その辺の気持ちよさは乗っててあるなっていうふうに思いますね。
車内もすごい静かなんで。
Speaker 3
あー良いですね。
Speaker 1
それは良いですね。
よくテスラの他の持ってる方に聞くと、
踏んだ瞬間の加速は結構他の車よりも、
Speaker 2
EVの特性なのかな、それがすごく良いみたいなことを言ってましたね。
加速に関してはすごいものあるんだろうなって思ってるんですけど、
僕は使ってないですね。
加速もモードが選べるんですよ。
コンフォートモードと標準モード。
もうちょっと高いモデルのやつとかだったら、
インシーンモードとか、
そういうより加速が強いモードっていうのがあったりするんですけど、
僕が普段使いしてるのはコンフォートモードってやつで、
あんまり踏み込んでもグッていかない。
それでも結構加速感じるなって思うんですけど、
そういう切り替えができるっていうのはあります。
加速すごいなって思ったのは、
試乗した時にテスラの方が運転して加速を体験したことがあるんですけど、
それはすごいなっていう感じですね。
グックってなる。
Speaker 3
モードを切り替えられるのがかっこいい。
Speaker 2
そうなんですよ。
やっぱりテスラ、ご存知か分からないですけど、
iPadみたいなのがついてるんですよね。
もうタブレットがバンって正面についてて、
そこで本当にiPadみたいに設定できたり、
ナビできたりとか、
あとYouTubeとかNetflixも入れたりとか、
いろいろするんですけど、
そこでいろいろできるのは、
エンジンに慣れ心をくすぐられるものがありますよね。
ですね。
あとAPIも公開してたりするんで、
サードパーティーのテスラのトラッキング、
どこ走ったかみたいなのも情報とかして取れたりするんで、
そういうのをグラフィカルに表示してくれるような
サービスを提供してるところもあったりしますし、
あと自分でも認証を通せばAPIコールして叩いて設定変更とか、
どういうのができるのかあんまり詳しく調べてないんですけど、
そういうのもできるんじゃないかなっていうふうに思ってて、
その辺とかは面白いですよね。
Speaker 1
面白いですね。
私も普段は車を運転しなくて、
車の乗り心地とか全然わかんないんですけど、
車の必要性
Speaker 1
テスラは結構ソフトウェアでアップグレードが来たりとか、
あとテスラの社員の方がおっしゃってたんですけど、
ソフトウェアを買えるんでしたっけ?
Speaker 2
買って車をアップグレードできるみたいな感じ?
そうですね。
はい。
でしたっけ?
そうですそうです。
その通りで、今購入することによってアップグレードできるやつは、
多分40万円のやつと80万円のやつとかがあるんですけど、
80万円のやつとかだったら、
FSDっていう、フルセルフドライビングだったかな。
究極的には目的地を設定したら、
そこまで勝手に運転していってくれるっていう機能とかは、
課金要素になってて、
それを購入することで使えるようになるっていうのが、
面白いところですよね。
そうですね。
日本では使えないとかいろいろあったりするんですけど、
Speaker 1
そういう感じですね。
エンジニア心をくすぶる、
Speaker 2
そうですね。
Speaker 1
ガジェットですよね。
そうですね。
ガジェットになっちゃうんですよね。
Speaker 3
大人なガジェット。
Speaker 2
そうですね。
開発環境といってもいいかもしれない。
APIも叩けるし。
Speaker 1
そうですね。
面白いですね。
Speaker 3
友人が仕事でTeslaのAPIを使った機能開発みたいにしてました。
Teslaを借りるというか乗れるんですよね、ユーザーさんが。
利用開始時間に合わせて、
遠隔で車の空調を自動でONにするみたいな。
夏とかに借りても乗った瞬間にすごい涼しくて快適なんですよみたいなのをやったりして。
こういうことできるんだと思って、めちゃくちゃ面白いなと思って。
Speaker 2
そうなんですよね。それいいですよね。
APIもそうだし、空調とかもアプリでいじれるんで、
そこら辺も本当に普通に便利ですね。
Speaker 3
めっちゃ楽しそう。
Speaker 1
楽しそうですね。
Speaker 3
これカズさん買うんですか、じゃあ次。
気になってるのかな。
Speaker 1
いやー、それがですね。
車買うんだったらTesla欲しいなと思うんですけど、
多分選ばないと思います、最終的に。
Speaker 3
なんでなんで。
Speaker 1
いやなんかすごい面白そうなんだけどちょっと。
Speaker 3
のめり込んじゃう。
Speaker 1
なんて言うんでしょう。
Speaker 2
もうちょっと楽しさよりも保守的に、新しいサービスよりも車に関しては、
今ある、
Speaker 1
枯れた技術。
EVじゃない枯れた技術の車を。
燃費とかを気にしたりとかして、
そっちをセーブするようなものを選びそうだなと僕は思ってますね。
Speaker 3
なるほどなるほど。
Speaker 2
その辺はネックではありますよね。
僕は多分、今一番不利な状態でEV買ってると思って。
どういうことですか。
なんでかっていうと、今僕はマンション住んでるから、
マンションというか賃貸のマンション住んでるから、
家で充電できないんですよね。
Speaker 3
充電ステーションみたいなの探さなきゃいけないってことか。
Speaker 2
そうなんですよ。
だから充電ステーションに通ってそこで充電するみたいな感じなんですよ。
だから持ち家の方とかだったら、
もう家にコンセント探して充電してとかできてるし、
それは非常に燃費がいいというか安いらしいんですよね。
ただ、テスラのスーパーチャージャーとか使ってる、
僕みたいなユースケースだと、
結構ガソリンにしたとほとんど変わらないぐらいの燃費、
みたいなコストがかかるっていう形なんで、
結構不便ちゃう、不便。
充電も時間かかりますし。
だからその辺は結構不便だけど、
Speaker 1
そういうのはわかりきった上で、楽しい方に振って今回は買いましたね。
わかります。
そっちに振り切っても全然いいし。
結局私にとっては車って、
多分買うとしたらただの移動ツールになってしまうのかなと思ってて、
楽しさよりもですね。
だからあえてテスラを買わないという選択肢になるかもしれないなと、
Speaker 2
個人的には思っちゃうんですよね。
Speaker 3
けんさんはどうですか。
充電ステーションの普及本当にあるなと思ってて、
僕が今住んでるロンドンのバロだから、
Cみたいな、シティみたいなところは結構そのEVの導入に積極的なので、
カウンシルが、自治体がどこまでお金を出してるのかリードしてるのかわかんないですけど、
少なくとも積極的にチャージポイントみたいにいろんなところに置いてるんですよね。
大きい乾電池みたいなのが地面からいきなりポンと生えてて、
多分テスラ以外もちろんいろんなEVがやってるから、
自宅からもう本当に数30秒ぐらい歩いたところでチャージしてますみたいな人も結構いたりして、
そのEV導入、買うってなったら多分そんなにそのチャージポイント的な意味では困らないところに住んでるから。
問題は僕が結構パブリックトランスポーテーションが好きなので。
なんか車を買うってなったらEVいいなって思ってます。
車を買う買わないのところがまず僕そこがすごいギャップがあるので。
多分。でもEV買うならEVいいなって結構思ってますよ。
Speaker 2
ハックしたいし。
Speaker 3
車がなくても全然生きていけるところに住んでるし、
ウォーカブルなのが好きなので、今はかな。
Speaker 1
坂尾さんは結構それでいうと車使うんですか?
隣に住んでるらしいの?
Speaker 2
そうですそうです。
東京の西の方なんで、
別に僕もいらないっちゃいらないんですよ、車。
完全に不要不急の車なんですけど、
ちょっと持ってみたいなっていう感じですね。
Speaker 1
いいじゃないですか。めっちゃわかります。
Speaker 2
何だろうな、旅行行った時に車でレンタカーで旅行行ったことがあって、
非常に便利だったんですよね。
荷物置きっぱなしにできるし、
結構旅行行く時にもちろん電車とか使うと使うこともできますけど、
結構移動が面倒かったり、帰り所に手が届かなかったりするケースもあって、
そういうのがあって、やっぱり車いいなっていう風になったんで、
ちょっとレンタカー乗ってたんですけど、
レンタカーって時間貸しで、
僕が使ってたのは日本のタイムスレンタカーっていうのを使ってたんですけど、
タイムスカーシェアカー。
何時から何時まで予約して使いますみたいな。
そういう感じなんですけど、
それをちょっと使ってて、
土日とかだったら全然履いてないみたいな状態が続いて、
ストレスが溜まり、自分でも欲しいなってなり、
車って興味あるのはテスラしかなかったんで、
テスラを買ったって感じです。
Speaker 1
なるほどですね。
そう、車の、私もベルリー住んでるんで、
基本的には車って不要ではあるんですけど、
やっぱり自分のプライベートな空間というか、
家族と旅行するときとか、
車って本当に便利というか、
例えば交通公共機関が混んでるとか、
そういう時に車が一つの、
家族で過ごせるプライベートな空間になっていいなと思ったりとか、
あとちょっと田舎の方に行くと、
GoからRustへの移行理由
Speaker 1
結局車の方が便利とか、
旅行に行くのに便利とかなったりあるんで、
結構悩みますね。
買うのか買わないのかっていうのはいくら年も出ますね。
Speaker 2
悩みますね。
Speaker 3
なんかめっちゃテスラの宣伝番組みたいになってるけど。
これ、坂尾さんのBDをもっと宣伝した方がいいんじゃない?
Speaker 1
そうそうそう。
じゃあ本編に戻りますか。
始まって少なかったです。
Speaker 3
テスラ買いたくなってきちゃうよ。
そうですね。
Speaker 1
じゃあ本編の方に、はい。
坂尾さんがBDをゴーラングからラストに書き換えたということで、
記事を全の方で公開もされてるんですが、
それについて深掘っていこうかなと思ってます。
最初なんですけど、
もともとゴーで実装されていたんですけど、
Speaker 2
もともとはラストで開発したかったんですか?
そうなんですよね。
もともとラストで開発したかったです。
Speaker 1
そうなんですね。
坂尾さんといったらゴーのイメージが強かったんで、
ゴーで書いてるのは、
Speaker 2
これはもともとゴーで書きたかったんだなと思ってたんですけど、
なぜラストで書きたかったのかなっていうのが気になってるんですけど。
そうですね。
ラストっていう言語自体に興味があって、
それを使うところをずっと探してたんですよね。
その中で、
もう数年前とかに、
このBDっていうものを作ってみようと思って、
作ったわけなんですけど、
その当時もラストにずっと興味あって、
まずラストでちょっと書いてみようと思って書いてみたんですけど、
勉強しながらですね、勉強しながら書いてみたんですけど、
全然わかんなくて、全然わかんなくてっていうか、
思い通りに動かなくて、
全然書けなくて。
全然書けなくて、そうなんですよね。
ちょっと諦めちゃったんですよね、その時は。
もうゴーの方が早く書けるわと思って、
早く世に出した方がいいんだと思って、
ゴーを使って書いたんですよね。
Speaker 1
なるほどですね。
それでVidiという素晴らしいオープンソースができて、
それからラストで改めて書き直したと。
そこでタイミング的にあったんですか?
もともとラストで書きたくてゴーで書いて、
次にラストでもう一回というか、
そもそもの目的であるラストで書き換えたわけじゃないですか。
実装の具体的手法
Speaker 2
タイミング、なぜ今だったのかみたいなところが気になって。
そうですね、ラストの勉強を結構続けてはいて、
社内の勉強会であったり社外の勉強会であったりも、
ラストの本を読んだりとかして、
結構やってたんですよね、ラストの勉強っていうのは。
で、やっぱりこれ手を動かさないと分かんないなっていう部分が出てきて、
結構知識は得たと。
じゃあもう実践的にラストをゴリゴリ書いて、
ちょっと身につけるフェーズかなっていうふうに思ったんで、
そのプロジェクト、もちろん新しいものを作ってもいいですし、
それはちょっと考えてたんですけど、特にアイデアもなかったんで、
非常にありがたいことによく使われているBidyっていうプロダクトを僕は持ってたので、
それをちょっとリプレイスしてみようっていうふうに思ったのがきっかけですね。
Speaker 1
なるほどですね。
結構やっぱラストを書く自信がある程度ついてきたという。
Speaker 2
そうですね。
ある程度。
タイミングなんですね。
本はいろいろ読んだしっていうところで、もう書けるんかなっていうふうに思ったんで、って感じですね。
最近はChatGPTもあるんで、大体書けるんですよね。
GitHubコパイロットも優秀で、大体関数書いたら定義してくれたりするんで、
そこら辺もなんかあるかもしれないですね。
結構新しい言語を書くっていうとこ、機にもそういうのを使える。
ラストの、例えばこういう、どういうふうに書くといいんだろうみたいなのも、
ChatGPTとかGitHubコパイロットに聞いたりとか、
これってどういう意味なんだろうっていうので、聞いたら教えてくれるみたいなのが非常に心強くて、
そういうきっかけもあるかもしれないですね。
勉強が非常にしやすくなってますよね、そういう。
Speaker 1
なるほど。
Speaker 3
それいい話ですね。
開発環境というかツーリングが進化してきた結果、
Speaker 2
自分がそれまでやろうとチャレンジしようと思ってたものに踏み出すサポートになったみたいな話で。
Speaker 1
それは結構強くある気がしますね。
そうですね。
それは確かに、私もそんな体験はないんですけど、
確かに最近コードを書くとき、やっぱGitHubコパイロットとかChatGPTの助けがあって、
いろいろ書きやすくなったもん、コードを書くのが。
それがなかった時期に比べれば全然サポートされるような気がしてて、
確かにコードが書きやすく、知らない言語でもコードが書きやすくなったっていうのは確かにありますね。
ある意味で、進化というか、開発環境の進化のことですね。
あんまり進化の途中ってあれじゃないですか、あんまり気づかないけど、
改めて振り返ってみると、これって大きな環境の変化だなみたいなのがあったりして、
Speaker 2
それが今なのかもしれないなとちょっと思いましたね。
Speaker 3
確かに。
今回、GoからRustに切り替えるときの切り替えの実装って、
Sakaoスタイルでいうとどういうふうにやってたのかなと思って、
プルリック的に言うと大きいのがバーンって出てるじゃないですか、
Speaker 2
Replace with Rustみたいな。
Speaker 3
多分、基本的には言語を切り替えるので、
ちまちまリリースしていくっていうのは、できるかもしれないけど結構めんどくさいから、
多分プルリックとして一つにまとめるって、最終形としてはすごい綺麗に見えるんですけど、
実際に書いていくものとしては一回Goのコードを全部消して、
ラストでフルスクラッチで書いていったのか、
どういうふうに結構機能漏れがないかとか、
APIが変わってないか、
CLIでいうAPIっていうのはアーギュメント渡したりとかだと思うんですけど、
そういうのを意識しながらどういうふうに切り替えの作業を具体的にしていったのかってめっちゃ気になるんですよね。
Speaker 2
そうですね。
いやもう、ビッグバンリライト、私力沢さんなんですけど。
力沢さん。
そうですね、もう完全にプライベートのレポジトリで作り始めて、
その当時はまずレポジトリ分けるかな、どうしようかなみたいなのをちょっと考えてたんで、
まずはレポジトリ分けて自分の手元で作ってたんですよね。
そこでGoのコードはなく、ラストのコードだけでゴリゴリ書いていって、
そうですね、まずは基本的な機能を作るっていうところですよね。
まずコマンドが実行されて、それが保存されていって、
それが履歴たどれるようにしていくみたいな、
まずそういう基本的な実装をまず作っていって、
それからインターフェースのところですかね。
CLIのアーギュメントのところであったりとか、
あそこら辺が大体機能になっていく、追加機能とかっていう形になっていったりするんで、
その辺を埋めていくっていうような感じですよね。
作って埋めていってっていう感じですね。
互換性のテストは正確にはあんまり多分できてなくて、
もちろん最初のUIで変えてる部分も、
変えてるUIを向上させた部分ももちろんあるし、
その辺は互換性もちろんないかったりするんですけど、
基本的な機能としての互換性は本当に自分でチェックしたりとか、
あとコミュニティに呼びかけて、
1.0.0っていうのをリリースしようと思うっていうのを、
GitHub Issueで、
まず公開する2ヶ月前とか1ヶ月前とかかな、
にIssue立てて、
そういう感じで大きな変更あるよ、気をつけてねっていうのを言ったのと、
ラストの実装ができたタイミングで、
Biggies Candidateのリリースをまずして、
もし興味あったらテストしてみたいな感じで、
Redditとかコミュニティに呼びかけたみたいなのはあったりしましたね。
Speaker 3
このコミュニティとの絡み方の話も今日すごい聞きたくて、
Redditで立ち上げたりとかすごい反応ついてますよね。
ファンユーザーみたいな人から、
It's really great stuff みたいな、
Awesome work みたいにいっぱいついてて、
なんかそのOSS的にも2、3ヶ月前にちゃんとヘッドアップ、
こういうのあるよっていうのをちゃんとアナウンスした上で、
ファンユーザーからの巻き込んで、
例えばバグレポートしてもらったりとか、
応援してもらったりみたいなのをやって、
ラスト実装を成し遂げたっていう、
一連の流れがなんかそのOSSの教科書的な感じで僕は感動してしまって、
Speaker 1
本当にそう思いますね。
Speaker 2
そうですよね、
まずこういうのがあるから辞められないんだな、
みたいな感じがしますよね。
本当にコメントもいただけたし、
プルリクとかですね、
一周見つけてプルリクも送ってくれたりとか、
そういう方がいたんで、
本当に支えになりましたし、
こういうのがあるからOSS開発楽しいし、
続けたいなっていうふうに思える、
いい出来事だったなって思いますね。
コミュニティとの関係
Speaker 2
素晴らしいですね。
Speaker 3
このVDのファンがいっぱい付いてて、
それが助け合ってる感がすごい、
コミュニティが温かくていいなと思いましたね、これは。
Speaker 1
そうですよね。
Speaker 3
坂尾さんのコミュニケーションとかアナウンスメントとかも
すごい丁寧に書かれていて、
一連のOSS開発としてのコミュニケーションスタイルも、
このプルリクすごい興味がある人は、
参考になるスレッドだなと思いました。
ぜひ読んでほしい。
Speaker 2
確かに。
Speaker 1
そうですね。
このRedditで呼びかけたのって、
やっぱそのRedditが
コミュニティの中で大きなプラットフォームだったりするんですか?
Speaker 2
どうだろうな。
そうですね。
でも結構以前から、
VD最初にリリースした時から、
RedditとHacker Newsかな。
で、投稿してこういうの作ったよみたいなのを
言ってたりはしてたんですよね。
あとたまに他の人もこういうツールがあってって言って話題にしてくれたりするのが
Redditだったんで、
僕の知ってる手段、
手段でしかないんですけど、
Redditでやったって感じですね。
なるほど。
Speaker 1
なんか私はRedditをそこまで使ってるユーザーではないんで、
私的には2チャンネルのようなプラットフォームかなっていうところがあったんですけど、
結構こういうところで使われてるんだなっていうのが新しい発見でしたね。
Speaker 2
なんかもし海外でどういうところにソフトウェアエンジニアがいるのかっていうのは、
僕もあんまり把握できてなくて、
知ってるのがHacker News、Redditっていうプラットフォームかなって思ってたんで、
そこに投げかけてるっていう感じなんですよね。
Speaker 3
Reddit、たまに見ますね。
たまにって言うと割と見るかもしれないですよね。
新しいやつリリースしたんだけど、
このライブラリの中の人ですみたいな、みんな感想くれみたいな感じで、
うちの会社の人とかも個人ライブラリアップグレードした時とか、
Redditにあげてたりします。
Speaker 2
やっぱRedditは結構メジャーなんですかね。
Speaker 3
今回坂尾さん、Zen.devで日本語の記事書かれたじゃないですか、
多分リンクも貼ると思うんだけど、
これ英語で書かないんですか?
Speaker 2
書いたんですよ。
Dev.toにあげてるんですよね。
Speaker 3
あげてるんですか。
Speaker 2
でもあんまり反応なかったから、そういうもんなんだなって思ってるんですけど。
どうなんですかね。
大体日本の聞いたZenみたいなのを、
海外版としてDev.toかなって思ってたんですけど、
大体その認識ってあってます?
Speaker 3
どうですか、かずさん。
Viddyのリリースについて
Speaker 3
僕Dev.toあんまり見ないかもしれない。
いや、知ってますけど。
Speaker 2
私も聞き…
そうですね。
聞かないかもしれないですね。
そうなんだ。
なんかどこにあげてるといいとか、
もしあったら聞いてみたいなって思ったんですけど。
Speaker 1
海外か。
やっぱ海外って自分のブログを持ってるようなイメージが強くて。
Speaker 3
海外ニュースとかもね。
Speaker 2
出てくるのかも。
Speaker 1
だからそこにポストするみたいなイメージがちょっと強いんですよね。
だから日本のような聞いたとかZenみたいなのって、
私が知る限りでは見たことないのかな。
Speaker 2
見たことないかもしれないですね。
Dev.toは確かにそうかもしれないんですけど。
Speaker 3
最近だとサブスタックとかあるかな。
初めて聞いた。
Speaker 1
ニュースレター?
Speaker 3
サブスタック.com。
ニュースレターみたいな。
例えば僕がブッククラブしてるタイリーファーストのケントベックとか、
あとDDIAのマーティン・クレップマンとかもここでブログを書いてたりしましたし、
そこは割とソフトエンジニアでも書いてて、
そのアプリとかでもRSSを読むみたいな感じで見れるんですよね。
Speaker 2
なるほど。
Speaker 3
Paywallも作れるし。
Speaker 2
いいですね。
ここに投げようかなと。
Speaker 3
そっか、Dev.toあったんだ。
ちょっとあとリンク送ってください。
今回新機能も結構実装されたみたいで、
新機能の実装とコミュニティの影響
Speaker 3
一緒にリプレイスしただけじゃなくて。
そんな話とかも聞いていいですか?
Speaker 2
はい、全然。
そうですね、新機能を作って、
最初はもうこれ作んなくてもいいかと思って、
一旦もう今までのGoのバージョンでリリースしてた機能のみを
実装すればもう一旦いいだろうっていう形で考えてたんですけど、
やっぱりRedditで宣伝した時に、
こういう機能ないのかって言われて、
その機能が前から一周もあったし、
要望も多かった機能だったんですよね。
その機能が何かっていうと、
コマンド実行結果の履歴保存して、
また後からそのビリのプログラムを一旦プロセスを落とした後でも、
また後から履歴見れたりとか、
そういうセーブ機能みたいなんですね。
ファイルに書き出しておくっていう機能ですかね。
そういうのを求められていましたと。
それで今回SQLiteに実行結果を保存して、
コマンド終了後も再度立ち上げて、
SQLiteを読み込ませると見れるっていう、
ブックバックっていう機能を作ったんですけど、
便利ですね。
それはそうなんですね。
コミュニティの人に言われたから結構作ったっていうのが、
OTですね。
せっかくだし作るかと思って作りましたね。
前からその機能が欲しいっていうふうには言われてたんで、
そういうのにも一応対応できるようにしようっていう形で、
今回リアーキテクチャというか、
内部の実装も変えてたりするんですよね。
だからこれをいずれ作る機能として見越してたんですけど、
V1.0に合わせて作っちゃえっていう形で作りましたねって感じですね。
Speaker 3
いいですね。
リライトをする過程で改めてソースコードを多分、
全て俯瞰してみたと思うんで、
それを踏まえて新しい機能拡張とかも、
ちょうどしやすかった時期なのかもしれないですよね。
Speaker 1
頭に全部入ってると思うんで。
Speaker 2
だいぶこれもスムーズにできましたね、そんなに苦労なく。
ありがとうございます。
Speaker 1
すごいですね。
この後、リリースしようと思って、
付け加えようと思ってる機能とかってあるんですか?
Speaker 2
そうですね。
結構イシューは溜まってる部分、
溜まってるというか予防はあるんで、
考えてるのはいくつかありますね。
そもそもそれはウォッチコマンドを 使えばいいんじゃないかなっていうのも
あるかもしれないんですけど、
リレッジを保存しないでメモリユーゼージを とりあえず抑えてくれみたいな機能要望があったりしたりとか。
あと、ちょっと大きいところで言うと、
今って最初にプロセス立ち上げた時に、
何秒間隔で繰り返しコマンドを 実行してくれっていうのを指定することができるんですけど、
それを実行時にも変えれるようにしたいみたいな、
インクリメント、ディクリメントするようにしたいみたいな要望とかがあったりするんで、
それはちょっとやろうかなっていうふうに思ってますね。
あといくつかいろいろイシューもあるんですけど、
Speaker 1
その辺をちょっと時間があるときに紹介していきたいなっていうふうに思ってますね。
Speaker 3
その1個目の…
Speaker 2
いいですよ、どうぞどうぞ。
Speaker 1
はい、OSSの作成者として、
イシューや要望としてコンフリクトするというか、
真逆の要望とか来たりするわけじゃないですか。
先ほど最初の1個目にメモリ効率を上げて、
こういう不要な機能はいらないからっていう、
ブックバック機能はいらないからっていう場合と、
ブックバック機能は欲しいよっていう新しい新機能みたいな、
でもメモリ容量は増えますよみたいな。
だからそこら辺の取捨選択ってどうやってるというか、
Speaker 2
どういうふうに判断してます?
むずいですよね、その辺は。
OSS以外もそうですよね、結構ありますよね。
Rustへの移行と今後の展望
Speaker 2
そうですね、これに関しては僕が作ってるOSSなので、
基本的に僕がプロダクトオーナーというか、
僕が全て決める権限があるかなと思っていて、
もちろんコミュニティの意見というか、
新しいユースケースが出てくるとかっていうのも大切だし、
それはなるべく応えたいなっていうふうに思ってるんですけど、
どうしても思想が違うなみたいなのは、
どうしても優先度落ちとっちゃうかなっていう感じですね。
なるほどですね。
そこはもう僕も時間も有限なので、
できるものとできないものがあるんでって感じですね。
結構やっぱ実装もどんどん複雑になっていくんですよね、大体。
いろんな機能要望に応えていっちゃうと、
それだけオプション増えていったりするし、
内部の実装も増えていっちゃうんで、
メンテナンスがしづらくなっちゃうなっていうのがあって、
なるべく本当にミニマルな、
なるべく実装しないみたいな、
なるべくミニマルにしたいなっていうのはありますね。
本当にそれが必要なのかみたいなのは、
Speaker 1
常に解いたいなっていう感じはちょっとしてますね。
Speaker 3
過去に実際にプッシュバックしたり、
リジェクトしたりした機能提案とかあったりするんですか?
Speaker 2
そうですね、答えられなかったのはありますね。
ちょっと期待持たせて答えられなかったなとかっていうのもあるし、
ちょっとそうですね。
例えば、今回ラスト実装になることによって、
多分これはどうしてもできなくなっちゃったなっていうのはあるんですけど、
Goのライブラリとして提供してくれないかみたいなのが話としてあったんですよね。
そうすると、他のGoのプログラムからこのBD呼び出して、
他のプログラムの機能の一部としてBDを使えるようにするみたいな。
そういう要望があって、
Goのライブラリで提供してくれるみたいなのがあったんですよね。
それはちょっと、今回答えられなくなっちゃったんですけど、
どうやら、この一周立てた人を見るのが多分フォークしてくれてて、Goのプログラム。
結構前からですね。前からフォークして、
確かカノニカルのプロダクトかなんかで使われてるのかな。
そういう形跡を見たことがありますね。
結局今回もまたちょっとラストになっちゃったんで、
そういう提供の仕方は難しいかなって思ってるんですけど、
そういうのもあったりしますね。
Speaker 1
それは面白いですね。
そういうふうに使いたいという。
Speaker 2
そうなんですよね。ライブラリで使いたいんだみたいな。
そうかと思って。
いろいろな要望がきて面白いなって思いますね。
やってると。
そうですよね。
Speaker 3
一連のコミュニケーションを組めて、
いろいろラーニングの機会があっていいなと思います。本当に。
Speaker 2
そうですよね。
Speaker 3
これアイコンはこのままなんですよね。
Speaker 2
アイコンはそうですね。このままかな。
ラストのカニに変わるのかなとか。
ちょっと考えたんですけどね。いろいろ考えたんですけど、
ゴファーはこのままで、
ラストのカニが映ってるテレビを見てるような形にしようかなとか。
いろいろ考えたんですよね。
このスポイトを持ってるのをカニにしようかなみたいなのとか。
いろいろ考えたんですけど、ちょっと今、
まあいいかと思って。
よほどの反対意見がないからいいやと思って。
このままにしようと思って。
Speaker 3
オリジナルをいつでも思い出させてくれる。
Speaker 1
そうですね。
Speaker 2
すごい特殊なプロトタクトというか、レポジトリになってますね。
実装言語がラストなのにゴファーをモチーフにしたアイコンっていう。
すごい特殊なレポジトリになっちゃったなって思ってます。
Speaker 3
いいですね。
Speaker 2
めっちゃいいですね。
Speaker 3
ビリーの今後、何かありますか。
目玉となる機能もやったし、
バグフィックスみたいなのもあるとおっしゃってましたけれども、
Speaker 2
一旦ラストにリプレイスしてちょっとやり切ったっていう感じはあるのかなと思いますが。
そうですね。基本的には一旦はやり切ったので、
細かい機能追加とかしたりとか、
あと互換性の問題とかもあると思うんで、
その辺はちょっとずつ直していくのと、
あと当初の目的として、
ラストの勉強がしたいっていう形でリプレイスしたんで、
内部のリファクタリングとかですね。
そういうのはちょっと進めていって、
自分のラストの学習の糧になればいいなっていうふうに思ってますね。
Speaker 3
いいですね。
これを聞いてくれてるリスナーで結構OSS開発チャレンジしてみたいとか、
ラストもちょっと興味あるんだよねみたいな人結構いると思うんですけど、
もしそういう方に向けて何かメッセージとかありますか。
ビリー関連で。
ここら辺のコードを見てもらうと勉強になるよとか。
Speaker 2
いや、むしろ教えてほしいですよね。
本当にまだラスト初心者が書いたコードっていう形だと思うんで、
もしラスト習熟者の人たちがいるのであれば、
ちょっと見てここ直して、
こういうふうに直すといいよとかあったら、
ぜひ教えてほしいですし。
そうですね。
ラスト初心者の方でOSSにコントリビュートすることに興味がある人にも、
そうですね、メッセージとしては僕が書いたコードちょっと微妙なところあると思うんで、
なんかそこ微妙だなって思ったら直して、
プリリック送ってくれればね。
高速で、高速かなどうかわかんないけどレビューして回しするんで、
ぜひコード見ていただけたらなっていうふうに思ってますね。
Speaker 3
いいですね。
Speaker 2
ぜひちょっと興味あるリスナーの方はチャレンジしてみてください。
Speaker 1
これで坂尾さん的には、
1から何かコマンドラインツールでもいいんですけど、
1からラストで書く自信ってどうですか?
Speaker 2
今なら書けるぜみたいな自信できました?
もちろん100%じゃないですけど、
Speaker 1
簡単なものならまあ書けそうだなっていう自信はつきましたね。
Speaker 2
あとは他のAIとかの助けもあれば。
AIの助けはやっぱり。
AIの助けがあればもう何でも別に書けますよ。
でも結構やっぱそのラスト言語難しいなっていうふうにやっぱずっと思いますね。
掘れば掘るだけなんか知らない機能があるし、
まだまだ勉強するべきことがあるなっていう感じがしてますね。
そこはちょっと頑張っていきたいなっていうふうに思ってますね。
Speaker 3
ちなみに今のBDのラスト実装で一番難しいハードだったパートとかってありますか?
例えばそのシールアイツールなんでアーギュメントをパースしてみたいなのは、
多分僕も使ったことありますけど、
クラップみたいなクレート使ってたりとか、
SQLiteのクライアント実装とかもあると思うんで、
ANSIコードとDiff機能の技術的挑戦
Speaker 3
そういうところはうまく他のクレート使いつつだと思うんですけど、
一番実装が困難だったBDのハードってどこかありますか?
Speaker 2
ちょっと頑張ったなって思うのは、
めっちゃニッチな話なんですけど。
Speaker 3
お、気になる気になる。
Speaker 2
結構そうですね、ニッチなんですけど、
ANSIコードってあるじゃないですか。
ターミナルで文字の色とか背景色変えたりですよね。
あれって難しいのは、
BDの機能でDiffを表示するんですよね。
前のコマンド実行結果、
2秒前のコマンド実行結果と今のコマンド実行結果の差を、
GitHubのDiffみたいな形で強調を表示するんですよね。
ここが文字がアッドされてるとか、そういう形で。
緑色の背景色で表示しますと。
もう一つは、
BDってページャー的な機能も提供してるんで、
例えばエンジンXって検索したら、
エンジンXっていう文字列がハイライトされるみたいな機能も提供してますと。
これは背景色黄色で表示されたりするんですよね。
これが両方同時に起こった場合みたいなのが若干めんどかったりするんですよ。
なんでかっていうと、
ANSIコードってここからここまでが、
例えばABCDEFっていう文字列があったときに、
後半のDEFをハイライトしたりするじゃないですか。
そうすると、
ABCでそのANSIコードをハイライトするための、
背景色を変更するっていう文字コードが入って、
DEFっていうのが文字列が来て、
その背景色をクリアするっていうANSIコードが入るみたいな感じですよね。
じゃあ今度、
ABCとCD、そこのANSIコードが入ってまたがってるところに対して、
また背景色を塗り潰す、
背景色を入れたい、ハイライトしたいっていうときに、
結構難しくなっちゃうんですよね。
なんだろうな。
なんて表現したらいいんだろうな、あれって。
だからHTMLのタグみたいな感じになっちゃうんですよね。
難しいな。
だからそういうふうに、
そのケースだったらどうなるかっていうと、
ABっていう文字列が来て、
そのCの前にANSIコード。
で、先ほどのANSIコードが残って、
背景色を変えちゃうCみたいな感じになっちゃうっていうイメージが伝わりますかね。
Speaker 3
HTMLタグと言ってるのは、
バリューをラップするような、
Speaker 2
入れ子構造になっちゃう。
で、入れ子構造になっちゃうから、
そう、ツリー構造みたいになっちゃうんですよね。
だからそこをコントロールするのがかなり難しくって。
だからどういうふうな解決策をしてるかっていうと、
一つの文字ごとに、
もうスタイル情報を持たせるっていう形に、
まず内部的に変換してるんですよ。
だからそのANSIコード。
Speaker 3
キャラクターごとですか。
Speaker 2
そう、もう完全にキャラクターごとに、
スタイル情報を持たせるっていう形に内部的に変換してて、
先ほどの入れ子構造を持った文字列を、
まずパースしてANSIコードを解析して、
この文字は黄色、
この文字は黄色で、
次になって青になって、
ANSIコードが来たら次からは青になって、
パースされていくみたいな。
青っていうスタイル情報を、
一文字ずつ持たせるみたいな感じにしますと。
なるほど、ANSIセクエンスを、
Speaker 3
キャラクターごとメタデータ的な扱いにした。
Speaker 2
そうなんですよ。
そうすると、
ここからここまでの長さの文字を、
背景色変えるっていうのが簡単にできるんですよね。
イメージできると思うんですけど。
それをした上で、
そうすると、
そういう先ほどのDiffの背景色と、
Pagerの背景色のコンフリクト問題っていうのが、
ある程度解決しますと。
なんでかっていうと、
結局ここからここまでは緑色にして、
Viddyのバージョン1.0.0
Speaker 2
ここからここまでは黄色にして、
みたいなAPIで叩けるようになると。
それで一段落ついて、
それからまたターミナルに表示させるために、
ANSIコードに直すっていうのを、
中ではやってるって感じですね。
分かりやすい。
Speaker 3
確かにキャラクター、
基本的にはストリングを扱ってる感じですから、
キャラクターの配列みたいな感じで、
キャラクターごとにメタデータ、
そしてANSI ESCAPE SEQUENCE持たせて、
そうすると多分、
ファンクショナル的にも書きやすいだろうし、
すごい納得ですね。
Speaker 1
そうですね。
Speaker 2
すごいニッチな。
いいですね。
頑張りがあります。
Speaker 3
やっぱりBillyの初回でも、
僕言ったかもしれないけど、
すごいナイスなUIとかUXを提供するために、
裏側のニッチな努力っていうのが、
妥協がない感じがすごい好きなので。
Speaker 2
そうですね。
Speaker 1
見た目的には簡単になってる。
Diffとか当たり前じゃないですか。
言っちゃうと、
僕らの世界で見えてるのっていうのが。
でもそれがテクノロジー的には、
中では結構複雑なことっていうか考えない。
実装できないっていうのが聞けて。
Speaker 2
そうですね。
めちゃくちゃ面白いですね。
Speaker 1
面白いですね。
Speaker 3
これで十分BTの魅力は伝わりましたかね。
Speaker 2
Teslaではなく。
Tesla強いからな。
そうですね。
是非レポジトリチェックして、
もちろん使ってみてくれると嬉しいですし、
またもし先ほども言いましたが、
ラストとかOSSコントリビュートに興味があるっていう方は、
レポジトリのソースコードまで除いて、
是非イケてない書き方を見つけて、
プリクとかを出していただけると本当に嬉しいので、
よろしくお願いしますって感じですね。
はい、そうですね。
Speaker 1
視聴者の皆さん、よろしくお願いします。
Speaker 3
はい。
Speaker 1
という感じで、何か言い残したことは坂尾さんありますか、BDリリース。
これ1になったんですね。
やっぱりこの1は狙ってたんですが、
バージョン1にするタイミングってなんか結構OSS見てると、
Speaker 1
なんか結構、いつまでバージョン1にならないんだっていうものとか結構見たことあるので。
Speaker 2
ありますよね。ありますけど、
そうですね、僕、これはまあ、
そうですね、今回5まではV0.4とかまでで、
マイナーバージョンで刻むって感じだったんですけど、
今回でV1.0、ラスト実装に変えることによってV1.0にしましたと。
そうですね、キリが良かったからですね。
実装言語を変えるほどの大きなリリースなのに、
メジャーバージョン変えないってことは許されるのかなっていうのはあんま分からなかったんで。
もう互換性も何もないぞみたいな、ライブレベルで見るとですね。
だからV1.0にしたっていう感じですね。
記念すべきリリースでした。
じゃあ、そんな感じで。
坂本さん、特に他に残したことはないですかね。
はい、大丈夫です。
本日はありがとうございました。
Speaker 1
こちらこそありがとうございました。
Speaker 3
おすすめです、BD。ぜひ。
Speaker 2
ぜひ使ってください。
59:57
Comments
Scroll