00:04
こんにちは、10X CCOのりっちゃです。
今回は、10X Tech Talkというイベントの音声をお届けします。
こちらのイベントは、4月19日に開催されました。
主にエンジニアの方向けのイベントで、
10Xで採用しているフルダート体制というものについてお話をしたイベントになります。
少しだけ説明しますと、10Xが提供するStaylerというプロダクトは、
裏側の言語については、モバイルアプリがFlutter、サーバーサイドがダートという言語で書いていて、
モバイルアプリもサーバーサイドも全部ダートの言語で書けるような開発体制をとっています。
今回のイベントでは、このなかなか珍しいフルダート体制をとっている10Xのエンジニアたちが、
ダートの良さを語り尽くすという回でした。
モデレーターがソフトウェアエンジニアの双川さん、
登壇者3名がソフトウェアエンジニアの岡野さん、
北さん、杉浦さんの3人でお話しした内容になります。
少し長いのですが、ぜひ最後までお聞きいただけたら幸いです。
それではどうぞ。
早速なんですけど、簡単に今日の登壇者の3名に、
一言、二言ぐらいで自己紹介いただければなと思うんですけど、
ソータさんからお願いします。
初めましての方、初めまして。杉浦ソータと申します。
10Xにも去年の8月に入社して、ソフトウェアエンジニアとして働いています。
ダートフラッターは入社してから完全に触っていて、
バックグラウンドとしてはバックエンディングエンジニアがほとんどで、
たまに趣味でウェーブフロントエンドをやっていたという感じです。
よろしくお願いします。
じゃあ、杉浦さん、自己紹介お願いします。
杉浦と言います。
会社では皆から来た系というふうに呼ばれています。
僕は2019年の4月に10Xに入社して、だいたい丸3年ぐらいですかね。
フラッターとかダートとかは、もともと僕入社したときには、
10Xタベリーっていうプロダクト作ってたんですけども、
それから1年とかして、ステラーという今の事業を始めて、
そのタイミングで僕も学び始めたという感じです。
僕のこれまでの経歴でいうと、
前職がウェブのフロントエンド専業でやってきて、
結構、ジャイバースクリプトとかタイプスクリプトとか書いてた感じです。
今日はよろしくお願いします。
じゃあ、次、金髪さんお願いします。
はい、岡田と申します。
社内では金髪って呼ばれてるんですけど、
こんな感じでお願いします。
ダートとフラッターは、
ダートはそれなりに昔からしてたんですけど、
フラッターを主にメインで始めたのは、
TX入社してからで、
TX入社したのは去年の5月なんで、
03:01
そろそろ2年経つっていう感じです。
経歴としては、社会人になってからは、
ずっとAndroidのアプリケーションを書いていたんで、
主にJavaとかボトリンっていうのを仕事で触ることが多かったです。
趣味でもいろんなアプロン言語を触ったりしてるんですけど、
そんな感じで、今日はよろしくお願いします。
じゃあ、双子さんに戻します。
はい、ありがとうございます。
そしたら早速、
順番にいろいろ話を聞いていきたいと思うんですけど、
最初のトークのテーマとしてはこちらで、
初めてダート、フラッターを触るときのキャッチアップってどうしてた?
っていうのをちょっと聞いていきたいなと思います。
これもじゃあ最初、そーたさんからお願いします。
はい、そうですね。
ダート、フラッター触るとき、
フラッターもダートで書けるっていう話あるんですけど、
ダートに関して言うと、
僕もともと仕事では、
PHPかNode.jsぐらいしか書いたことなかったんですけど、
割と書き味とか文法とかもそんなに、
何だろうな、
何か規定列じゃないというか、
割と似てるなって印象があって、
読むのは何となく読めるぐらいだなっていう感じだし、
書くときも、
書き始めたときは、
入社時の専攻のときにも初めて書いたんですけど、
既存のコードを読みながらとか、
あとは分かんない文法とかはちょっとググりながら書くっていう感じで、
ダートは割とそんな感じで書けたなっていうような感じですね。
フラッターのほうは、
その文法だけ分かってても動かないんで、
最初は公式ドキュメントのチュートリアルみたいなところを、
2日ぐらい、1日ぐらいで読んで、
2日ぐらいかけて、
実際にプロバイダーかな、
プロバイダー、一番プレーンなステート管理のやつを使って、
手元で動くアプリをちょっと書いてみて、
それをやってから既存のコードを読みに行って、
なるほど、現実こんな感じで書くのかっていう感じで、
キャッチアップしたなっていうような感じですね。
もともとリアクトJSを僕は結構書いてたんで、
その知識とか、
ステートに対する考え方とかが、
割とそのリアクトを書いた経験を基に、
フラットに向き合うと、
すんなり入ってきて、
割と書きやすいなと思った印象ですかね。
なので、その辺りはバックグラウンドが結構違う、
喜武さんと岡野さん的には感覚どうだったかっていうのは、
聞いてみたいところですね。
じゃあ喜武さん、さっきの話の順番に言うと。
06:03
言語的に言うと沢田さんおっしゃった通り、
全然癖がない言語っていう感じですよね。
もともと僕は、さっきも話した通り、
もともとJSを書いてて、
もともとダートが、
ブラウザーのJSを置き換える目的で生まれた言語だったのもあると思う。
結構似てるんですよね。
僕個人的な印象としては、
Javaの革をかぶったJSみたいな風に、
ダートのことを。
1個1個の名前ちょいちょいJavaっぽいんですよね。
JavaScriptでいうプロミスが、
フューチャーって名前になってたりとか。
分かるかも。
型アノテーションの位置とかもJavaっぽいですよね。
そうなんですよね。
なので僕からすると結構すんなり学ぶことができたかなという感じがします。
あとFlutterに関して言うと、
結構公式ドキュメントが充実してるんですよね。
多分これ一通り読めばやりたいことはできるんじゃないかなと思います。
結構ビジェットの種類が豊富なんで、
このビジェットがどういう役割するかとかは、
公式の実装サンプル集って言えばいいのかな。
ギャラリーってやつがあって、
それを動かしてみたりとか、ソースコード読んだりとかして、
こういうUI作るときこういう風に書けばいいんだ、みたいな感じで学んでいった感じですね。
分かるかも。
ビジェットの充実具合は確かにめちゃくちゃ良いというか、
取っ付きやすいなと思った記憶が僕もありますね。
多分、よほど特殊なUIのものを作らなければ、
大体ありものを組み合わせるだけでいい感じになるし、
あとは、ちょっと話はずれますけど、
このビジェットどう使うんだろうなって思ったときに、
大体YouTubeに1分か2分くらいの動画が公式で上がってて、
それ見ると1、2分くらいでノリが分かるから、
読んで書いて動かして、
ワイワイみたいな感じでやった記憶があります。
Androidの経験を、バックグラウンドがあるほかのさん的には、
Flutterはどうですか?
そうですね。
僕はそもそもダートっていうのが出てきた当初から、
なんとなく触っていた勢なんですけど、
そんな感じだったので、
さっき竹井さんが言った通り、
ダートが初回出てきたときの印象とか、
今でもそうなんですけど、
これJavaに似てるなというか、
特殊なことがそんなにないというか、
そういう印象はやっぱりあって、
当時Androidを書いていた僕としては、
Javaをメインにやっていたので、
普通にダートっていう言語自体は、
それなりに手が馴染んだかなという感じですね。
キャッチアップとかは、
公式ドキュメントとかいろいろあったりとか、
09:01
パッケージ管理は公式のがあるので、
そういうとこはそんなにつまずかないかなというので、
FlutterはTXに入社する前ぐらいから、
いや、嘘だな。
Flutterは一番最初僕が何で触ったかというと、
当時Flutterの勉強会をやっているコミュニティがあって、
そこで登壇したいなと思って、
そこが多分一番最初のFlutterの入り口だったんですね。
そのときいきなりアプリケーションを作るんじゃなくて、
プラグインと呼ばれるようなライブラリを
いきなり作るというところから入って、
いまだに何を作ったかというと、
FlutterからAndroidとiOS、
それぞれのプラットフォームの広告IDを取得するライブラリを作ったんですけど、
実際にそれいまだにOSSでメンテしていて、
うちの社内とかでも使っているんですけど、
そういうのを一番最初に作ったのが多分Flutterの入り口。
当初何でそれをやったかというと、
やっぱりFlutterをやっている人が少なかったし、
ネイティブとのブリッジをプラグインで書いている人が少なくて、
これは書いておけば先行者によって得られるだろうと思って多分書いた。
やっぱりそれがしっかり、今そんなに利用人数が多くないんですけど、
使っている人たちが結構いるので、
そうやって入っていったのが初めてかな。
そこから1年ぐらい経って、
TXに入社しようかなと思って触り始めて、
個人アプリを、
トゥードゥ管理アプリじゃないな、
ストップウォッチみたいなアプリを作って遊んでたんですけど、
多分それが一番最初っていう感じですね。
その時も実際に触ってみたりとか、
公式のドキュメントを見ながら、
どうやって書くのかなみたいなのを調べた感じですかね。
そんなにキャッチアップは大変じゃなかったかなというところはあります。
なんかあれですね、皆さん結構、
公式のドキュメントを見たりとか、
YouTube動画があったので見たりとか、
実際作ってみて手を動かして、
キャッチアップしていくみたいな流れがやっぱり多かったのかなっていう感じですかね。
そうですね。
ドキュメントがやっぱ、
コツサラフラッターに関してはだいたい整ってるから、
あんま困ったことないかなって気がしますね。
困ったことあるかな。
キャッチアップに関して困ったことない気がするな。
言語特有の癖とかもそんなにないでは、
他のもうちょっとリッチというか、
例えばセイフトとか、
Rubyとか、
そういうところから入ってきたり、
ちょうど触るときに、
なんでこういう機能がないんだろうとか、
そういうのはあるかもしれないんですけど、
でも何だろう、
愚直に普通のことができる言語っていう意味では、
良いかなという、
差別化にはなってないんですけど、
12:02
触りやすいという感じがしますね。
確かにな。
派手じゃないけど、
でも必要なもの全部揃ってる感じが、
個人的には感じますね。
多くの人がタイプスクリプトから来たというか、
タイプスクリプトを書いたりするんで、
だと一応その肩回りの機能もあるんですけど、
TSと比べるとこれ欲しいなみたいな思うけど、
別にそれなくても、
普通にチーム開発はできるよねみたいな思いながら、
触ったりしてる部分もあるし、
未だにその言語自体が、
アップデートし続けてはいるから、
そんなに別に、
今時点で完成してるわけじゃないっていう意味では、
そんなに、
多分コミュニティにフィードバックすれば、
良い言語になってくだろうなっていう気持ちで、
伝わってるかもしれないですね。
事前の質問でも、
スウェーフトとの違いみたいなことを言ってる人がいましたけど、
そうですね。
コンパスにスウェーフトとの違いって来てたりとか、
あと今ちょっとチャットの方で、
ダートフラッターがどういうのか具体的なお話が聞きたいですっていう風に、
質問してくれてる方がいて、
これは、
もし可能だったら、
もうちょっとどういう側面での具体的な話が聞きたいとかを、
質問いただけると、
答えやすいかなと思いますね。
割と今言語ごとの比較した内容は、
お話結構あったと思うんですけど、
フラッター、
そうですね、
フラッター、
まずフラッターに採用された言語がダートっていうのは、
1個いい面があるかなと思っていて、
そんなに表現力が高くないというか、
そんなにマジックみたいなことができないので、
フラッターを宣言的にUIとして書く部分で、
そんなにマジックみたいなことができないというか、
みんな多分愚直に書けばこうなるよねっていうのが、
1つ良かったのかなと思っていて、
フラッターにダートが採用されて具体的に良かったと思っているのは、
僕は個人的にそこだと思っています。
あとフラッターの面から見たときに具体的な良いことっていうのは、
ウィジェットが整っているっていう背景として、
基本的にデフォルトのウィジェットのUIとかって、
マテリアデザインを多分ベースにしてるんですよね。
なので基本的に、
例えばAndroidから入ってきた人達であれば、
マテリアデザインがベースになっているので、
そこのマテリアデザインをベースとした知識っていうのが、
フラッターのUIでもそのまま使えるので、
そこら辺に迷いがないっていうのは良いし、
かつマテリアデザインにのっとっているからこそ、
よくAndroidとかで昔あったような、
特殊なビューとか、
結構オシャレにグリグリ動くビューとか、
そういうのがあまり再開発されない。
フラッターデフォルトのUIがしっかりアプリケーションに反映されて、
それを組み合わせるだけで、
それなりのアプリケーションが作れるっていう土台があるっていうのは、
15:00
フラッターとして具体的に良いところだったのかなと、
僕は思っています。
めちゃくちゃ良いコメントだ。
ありがとうございます。
さっき米田さんが多分質問してくれたんですけど、
どうですかね。
ちょっと次の話題に行きましょうかね。
ダートフラッターの開発環境ってどうですか?
っていうところを聞いてみたいなと思ってまして、
言語として書き心地は素直だよね、
マジックないよねみたいな話があったんですけど、
書く環境とか、取り巻く状況とかってどうなんですかねっていうのを、
そうしたら、これは北桂さんから聞いてみようかな。
お願いします。
正直これ深く語れるかは自信ないんですが、
とりあえず普段どういうふうにやってるかっていうと、
まずフラッターの開発はAndroid Studioでやってます。
普通にフラッターのデバッグするときの、
そのウィジェットのインスペクターとかもちゃんと動いてる感じですね。
サーバーサイドの開発するときは、
Android Studioつながりで、僕はIntelliJを使って書いてます。
なんかあんまり語れることないんだよな。
多分会社の中には二つ派閥あると思ってて、
Android Studio、IntelliJ系の人と、あとVS Code系の人。
確かにありますね。
僕最初に開発環境をセットアップしたときは、
まだ二つ一応選択肢あるんだけど、
どっちかというとAndroid Studioの方が充実してたというか、
発展してた気がしてて、それを選んでずっとここまで来ちゃったんですけど、
中にはAndroid Studioの重さとかに耐えきれなくなってしまって、
VS Codeに移行した人も何人かいたんじゃないかなと思ってます。
それで言うと、金髪さんはどっちですか?
僕は全く北桂さんと同じ構成ですね。
フラットを書くときはAndroid Studioで、
サーバーサイドアートを書くときはIntelliJですね。
なるほど。
それで言うと、僕もその構成なんで、
ちょっとVS Codeセンスはできないですね。
ただ、社内のシェアから見ると、
多分どっちで確認してもエコシステムは十分整ってるんだろうなっていうのは、
状況から考えると言えるのかなって気はしていて、
エコシステムっていうのは多分Dartのプラグインとかもそうですし、
Lintのプラグインとか、
諸々のIDから受ける基本的なサポートっていうのは、
多分どっちを使っても十分に受けられるんじゃないかなって気はしますね。
それで言うと、僕はVS Code勢なんですよね。
聞きたい。
もともとAndroid StudioでFlutter入って、
10Xで業務で使うようになってからVS Codeに移行したみたいな感じですね。
18:02
サーバーサイドのDartもFlutterもVS Code使って書いてて、
僕は、
名前が飛んじゃったんですけど、
Dockerで開発できるじゃないですか、VS Codeだと。
リモートコンテナ。
そうですね、リモートコンテナ。
あれがやっぱりめちゃめちゃ便利で、
環境構築とか手元でする必要ないんで、
サーバーサイドとかは基本あれでやってますね。
なるほどですね。
リモートコンテナの人多いよな。
ちなみにAndroid StudioとIntelJで開発してて、
若干どうでもいい困りポイントとしては、
派生が同じIDEなんで、
UIにすごい似てるんですよね、外面。
2つアプリケーション立ち上げたときに。
かつ僕、IntelJとAndroid Studio両方とも、
テーマを同じカラーにしていて、
黒い背景のやつにしていて、
たまにサーバーサイドDartの方に、
IntelJの方にフォーカスを当てたと思ったら、
Android Studioの方のやつを開いていて、
かつ両方とも言語としてDartじゃないですか。
どちらどちらみたいにたまになるっていう、
どうでもいい困りポイントになりますね。
テーマ回路という話なんですけど。
僕、実はFlutterもIntelJでやってるんですけど、
Android Studioの方がいい理由とかってあるんですか?
僕も最初IntelJでやってました。
でも、何となく分けたいなと思って分けたっていう。
それだけですね。
なるほど。
特に多分大きな差はないのかな。
あとは、めちゃくちゃ詳しいわけじゃないんで、
アッサイコメントしかできないんですけど、
デバッグの時に名前忘れたな。
デバッグコンソールみたいなのが出せるじゃないですか。
UIの。
何だろう、名前が伝ってない気がする、これは。
デブツールとか。
4つぐらいタグがバッと出るやつですよね。
そうです。
Chromeがバッと勝手に立ち上がって、
データ上でクリックした場所のビジェットの情報とかが見れるみたいなやつがあるんですけど、
あれは結構、どうだろう、僕ネイティブの出身じゃないんで、
セーフトもコットにもあるよって話になるかもしれないですけど、
あれは結構便利だなと思いながら開発してますね、
Flutterに関しては。
Flutterになってからデブツールとかデバッグとか全く使ってないな。
ホットリロードが優れてるんで、怪しかったら、
21:00
変数とか見たかったら一旦プリント文書いてみてとかで、
ホットリロードすぐに実行できるから、あんまりデバッグはFlutterになってから使ってないですね。
なるほど。確かにホットリロード早いっていうのは間違いないですね。
何に使ったんだろうな。
あと開発環境っていう面では、
1つなんかちょっとIDとかから外れるんですけど、
FlutterとかDartそのもののバージョン管理、
要はローカルでインストールしてるときに、
Flutterのバージョンとか合わせないとエラーになると思うんですよね、
いろんなバージョン入れてると。
個人でも僕たまにFlutterとかDartを触るときに、
個人でやってるアプリケーションのDartとかFlutterのバージョンと、
仕事でやってるときのFlutterとDartのバージョンが違うので、
要はノードで言う、
ノードとかRubyとかいろいろあると思うんですよね、バージョン管理。
それのために一応サイドキックっていうやつがあって、
それを使ってバージョンの切り替えとかを、
ちまちまちまちま簡単にできるっていうのをやってますね。
意外と社内でたまにこれ便利ですよって言うんだけど、
誰も反応がないっていう。
そう、ちゃんと見てますよ、そのSlackの投稿は。
便利そうだなと思って見てます。
リンクをチャットに貼ってくれた人がいる。
そうですね、他の言語とかに必要なエコシステムはだいたい揃ってる感ある気がします。
これもしっかりですけど。
DevToolsのインスペクター以外は疲れてますか?
疲れてるのはどういう場面で役立つことが多いですか?
僕は今のところ使ったことないですかね。
インスペクター以外。
多分、TenXのアプリでまだ起きてないだけで、
クライアントアプリ側のパフォーマンスがIoT以外で落ちてきた時とかには、
きちんと使わなきゃいけないのかなっていう気はなんとなくしてますけどね。
DevToolsとかって具体的にどういう機能があるのか、
僕あんまり使ってないんでわかんないんですけど、
全職でナクスト、いわゆるビューをやってた時には、
Chromeのエクステンションとかでステートが見れるとか、
そういう機能があったんで、
そういう機能に近いものがいろいろあるんだったら、
ちょっと嬉しいかもぐらいかな。
ちょっとわかんないです。なんとなく言ってみました。
ちなみに手元で開いたやつだと、
例えばCPUプロファイラーとかメモリとかネットワーク周りとかが使えるって感じですけど、
その辺開くのって多分パフォーマンスが死に始めっていうか、
24:04
死ぬ兆候が見えたタイミングとかに触り始めるのかなって気はしてますね。
ちょっとぬるっと質問を拾っちゃいましたが。
ありがとうございます。
今のお話の中でもあったと思うんですけど、
ライブラリー周りとかエコシステムみたいなのがちょっと出てきていて、
その辺で例えばこれまで書かれてきた言語と比べてどうなのかなとか、
それこそ社内でダートのライブラリー作してたりとかすると思うんですけど、
そこら辺の話とかもしできたら聞いてみたいなと思うんですけど、どうでしょう。
これはそしたら最初金髪さんに言ってみますか。
そうですね。
僕自身は一個Flutterのアプリケーションのプラグインっていうものを開発しているので、
でも数年前と比べると、
Flutterの面で言えばネイティブとブリッジするようなパッケージは結構増えてきたかなと思っているので、
例えばうちが提供しているStaylerっていうようなネットスーパーのアプリとか、
あと普通のECサイトみたいなのを作るってなると、
そんなにライブラリーとかエコシステムみたいなので困ることっていうのは、
そうそうないのかなとは思ってます。
その反面サーバーサイトだとについては何がライブラリーとかがないかっていうと、
主に外部システムの連携とかでライブラリーがないっていうのはたびたびたまにある。
それでも結構開発している方がそれなりにちらほらいるので、困らないっちゃ困らないんですけど、
例えば日本の決済のペイメントの会社のAPIとつない込みたいとか、
そういうところになってくるとダートのライブラリーっていうのは多分あんまりないので、
そういうのは自分たちで開発するとか、そういうことはあるかなと思います。
エコシステム全体としてはPubっていうデフォルトで入っているパッケージシステム管理があるので、
そんなに困ってないかなという感じがします。
これ全部僕が喋っちゃうと、次喋る人がいなくなっちゃうので、
Sotaさんにお渡しします。
そうですね。基本おっしゃった通りって言っちゃうと終わっちゃうんですけど、
ちょいちょいないっていうのは事実として確かにあるなと思って、
入社してからあったんだと、エラスティックサーチのクライアントが一応使ってるやつがあるんですけど、
あんまりめちゃくちゃアクティブにメンテナンスされていないから、
プリリック送るかみたいなことがあったりとか、別のライブラリでもちらほらそういうことがなくはないかなっていう。
27:02
そのあたりは他のソースね、それこそRubyとかNode.jsとか、
PHPとかもあるかな、あとGoとかですかね、
の発展具合と比べるとまだちょっとこれからかなっていう部分はあるかなっていう気はしますね。
あとはリンターが個人的にはあまり使いやすくないんだが、
その一周に対して弊社のエンジニアが実は社内用のリンターを作っていたりするんで、
そういう、なんでしょうね、
そういうのはゆくゆくOSSにしていけたらいいねっていうのをちょっと今話を聞きながら思い出したりしました。
そうですね、ライブラリシステム。
まあでも基本的にそんなになんだろうな、
これはないとダメでしょってやつはさすがにだいたい揃ってる感はあるから、
あんまり作ればいいかなぐらいの気持ちで済むことが多いかなって気は、感覚としてはありますけどね。
木竹さんどうですか、そのあたり。
まあ本当ソードさんおっしゃってる通りだなと思ってて、
必要なものはだいたい揃ってると思うんですよね。
あとはなんか個々の成熟度合いという感じかなと思ってて、
なんかすごい具体の話ですけど、
なんかクッキーのパーサーがちょっとエッジケースに対応できてなくてエラーになっちゃったりとか、
それは結構サードパーティーのライブラリいろいろありますよね。
うんうん、確かに。
いやー、確かにエッジケース感ありますね。
僕個人的にはいけてないところもあるかもしれないんですけど、
リンターとかテスティングフレームワークが公式で用意してくれてるのすごい嬉しいなと思ってて。
あー、確かにテスト公式なのは確かにですね。
結構WebFrontとかNode.jsだとその時その時で、
まあなんとなくデファクトスタンダードのものあるんですけど、
移り変わりが結構いろいろあったりとかして。
めっちゃわかります。
Goの時もちょっと感動したんですよね。
あ、なんか公式テストコマンドあるんだと思って。
なんかずっとNode.jsの人だったんで、
まあ、きたけさんおっしゃる通り、いろいろ自分で選べるとかはいいかもしれないけど、
まあそれよりは多分、
まあ筋がいいっていう前提は必要だと思うけど、
言語がこれ使ってねみたいなのがあるの方が、
まあ無駄な議論がなくていいなっていうのは完全に合意ですね。
16分前にされた質問があるんですけど、
なんかちょっと僕はネイティブな人間じゃないんで、
金髪さんに聞いてみたところなんですけど、
KotlinとSwiftでプラグインなどを開発する必要があるのかどうかみたいな、
まあスマホ開発にフラッター並みで十分なのかみたいな質問が来てるんですけど、
この後はどうなんすかね。
今だったら特殊なことしなければだいたいフラッターで完結できるのかなと勝手に僕は思ってたんですけど。
30:04
そうですね。
まずテイク社内のStaylerのアプリ、
主にお客様アプリって言われる一般のユーザーさんが利用するネットスーパーのアプリの事例だけで具体的に言うと、
たぶんあれってほぼほぼ僕たちがネイティブ、SwiftとKotlinで用に書いてるコードたぶんないですよね、確か。
確かないはず。
基本的にはOSSとかコミュニティで作られているパッケージ、
要はプラグインとかだけで構成されているので、
僕たちがお客様アプリを開発していて、
自分たちでネイティブのブリッジのコードを書かなくちゃいけないっていうことがなかったはずっていうのは、
一つ事例としては大きいんじゃないかなと思っていて、
要はそれは基本的OSSとかで開発しているものに乗っかれば、
それなりに普通のアプリケーションを開発できるっていう状況なので、
それは一つ伝えられるものなのかなとは思っています。
個人的に、
そうですね、僕も個人でプラグインを作ってましたけど、
そうやって結構先人の人たちが作ってくれたものがあるので、
メンテナンスされてないものもあるかもしれないんですけど、
あとはダートの公式みたいな、
GitHubのオーガナイゼーションのところに、
それなりに普通に、例えばAndroidのアプリで使う、
例えばシェアドプリファレンスと、
例えばiOSであればキーチェーンみたいな、
そういうところの基本機能を使うためのプラグインっていうのは、
多分あそこの公式でしっかりメンテナンスされているので、
そういうところは特に不満というか不安がないというか、
なので割と普通に、
今だとそんなに自分でiOSとか、
いわゆるSWIFTとかオブジェクティブCとか、
Javaとかコドリーを書くケースっていうのは、
ほぼほぼないかなと思います。
追加で、例えばUberEatsのようなアプリは、
Flutterだけで開発可能でしょうかという質問をいただいています。
いや、できるんじゃないですか。
だってGoogleマップ使えるし、
例えばUberEatsみたいにマップをどうリッチに作るかっていう問題はあると思うんですけど、
なんかパッと見そんなに特殊なことはないかなという気がしてます。
そうですね。裏側でめちゃくちゃ何かが走ってるとかじゃなければ。
例えばじゃあ、僕とか颯太さんがもともといた会社でメルカリっていうのがありますけど、
今ちょっとメルペイの機能が入っちゃってるんであれですけど、
例えばメルペイが入る前のメルカリをフラッタで今書いてくださいって言われたら、
多分普通にフラッタだけで書ける気がします。
33:01
確かに。
なんかそういう具合ですね、多分。今で言ってフラッタ。
ありがとうございます。
そうですね。ちょっとそしたら一個事前のトークテーマね。
僕が聞きたかっただけなんですけど、
最近ダートで書いたイケてる実装を教えてくださいっていうのをちょっと聞いてみたいなって思うんですけど、
どうですかね。これは颯太さんからお願いします。
そうですね。イケてる、パッと思いつかないんですけど、
ダートだからイケてるみたいなのが難しいなっていう。
綺麗なコードを書いたなみたいなことあるけど、
これがダートだから綺麗だったよねみたいなのはあんまパッと思いつかないなとは思いつつ、
個人的にはダートのサーバーサイド、フラッタでもできるんですけど、
エクステンションっていう機能があるじゃないですか。
あれは結構うまく使うといい感じに書けるなっていうのは最近というわけではないんですけど、
思ったりしてますが、
お二人的にはイケてる実装とか、この機能を使いこなしたらいい感じになるみたいなのありますか。
結構難しい。
そうですね。イケてるかどうかわかんないんですけども、
ゾーンっていう機能があって、これ結構最近使ったら便利だったんですよね。
ある関数呼び出しのコールスタック内をまとめて扱える仕組みで、
ちょっとうまく説明できてるか自信ないんですけども、
そのコールスタック内で発生したエラーとか例外とかをまとめてハンドリングできたりとか、
あとはそのコールスタック内でグローバル変数的な感じで値を共有できるような仕組みがゾーンっていう名前であるんですね。
例えばなんですけど、これどういう時に使うと便利かっていうと、
サーバーサイドの実装でリクエストが来た時にリクエストIDみたいなものを割り振って共有して、
ログに出力するときにそれを参照するようにしたりとか。
あとは最近僕やったのだと、うちデータベースにファイヤーストア使ってるんですけど、
コネクションプーリングって複数事前にコネクション用意しておいて、
それを使い回すような実装にしたんですよね。
リクエストが来たときにプールしてあるやつから1個コネクションを選んでリクエストに割り当てるみたいなことをやったときにも、
ゾーンって仕組みがなかった場合は、コネクションをいろんな関数とかメソッドの引数としてたらい回しというか、
引き継いでいかないといけなかったんだけども、
このゾーンの値を共有できる仕組みで結構うまく実装できたんじゃないかなっていうふうに思ってます。
なるほどですね。めちゃくちゃいい知見ですね。
ちなみに僕は知らなかったです。
ちょっとキャッチアップしよう。
36:00
金髪さんどうですか?
いやーどうだろうな。
僕がやったイケテル実装みたいな話はできないんですけど。
そうですね。イケテル実装というか、こういう感じで実装もできるんだなとか、
それこそOSSのコードをいろいろ読んでみて、
なんか面白そうだなみたいなのは、
例えばテスティングのライブラリとか最近読んでたんですけど、
そこらへんでも結構いろいろ、
ダートはダートなんだけど、こういう書き方もできるんだなみたいなのとか、
そういう標準でついているSDKのこういう機能があるんだなみたいなのは、
結構そういうライブラリを読んでいると気づきが多いですね。
あとはちょっとFlutterとかそういうところから離れるとなると、
WebのCSSのフレームワークにSASっていうのがあると思うんですよね。
あれの実装、裏側の実装って今実は多分メインはダートで書かれていて、
それの実装とか結構ダートのOSSのツールの中では、
結構そんなにコード量があるかなと思っていて、
あれとかは結構深く読んでみるとなんか面白い実装がたまにあったりしますね。
それはFlutterと関係なくダートっていう言語自体を結構それなりにうまく使っているOSSではあるので、
結構それを読んでいるとそれなりに勉強になることは多いですね。
この辺はちょっと後ほどリンクを貼ってPodcast公開の時に紹介しましょう。
もうすでに貼ってくれてる。
知らなかった。読んでみよう。
これはかなりダートの中でもコード量がそれなりにあるものだと思います。
これスクラッチで作り直してるってことですよね。
こっちがもともと別の…もともとって何の実装だったっけな、なんかRubyかな?
なんか別の実装で書かれていたんですけど、
何年か前にダートで書き直されてるはずですよね。
もともとはRubyでした。Rubyで書かれたんですけど、ダートで大体に書き直したっていう感じですね。
ちょっと後で読もう。今読んだら黙ってしまう。
とりあえずスターだけ付けときました。
1個だけ僕もちょっと紹介したいのがあって、
これは僕が書いたものではないんですけど、
同じようにそのライブラリテスト系のやつなんですけど、
社内でも使ってるクロックっていうライブラリーは結構いいなと思っていて、
39:02
Staylerで配送とかあって、この時間に受け取りたいみたいな時とか、
あと注文がこの時間までしかできないとか、結構時間の絡んだ機能がたくさんあるんですけど、
そういう時に時間を固定したりとか境界値をテストしたりとかっていう時に、
このクロックを使うと、この言い方が結構一般的なのかわかんないですけど、
The Worldができるというのがよくて、
時間を固定し止めることができるっていうのがいいなと思ってます。
それがあるおかげで結構時間回りのテスト書きやすかったりとかはあるかなと思いますね。
確かに。
このクロックって公式のやつなんでしたっけ?どうなんだろう。
結構公式面してますよね。
公式面。
公式面。
こういうの結構乱立するイメージあるけど、DARTはこれ一択感があって、
安心して使えるなと思いながら使ってます。
そうですね。
すごいエコシステムの話と絡むかもしれないですけど、
分断があんまりないっていう感じもあるので、
割と一個選んだものが安心してずっと長年使えるっていう感じはありますね。
確かに。
これユーザーめちゃくちゃ増えたら分断すんのかな。
そうなったらそうなって僕らは多分嬉しい気がするけど。
ありがとうございます。
一通り事前に用意していたトークのテーマをバーッと話ができて、
今あと15分くらいかな?1時間なので、
もうちょっと質問いただいてるところから話していけたらなと思うんですけど、
フラッター開発に扱いにくい面はありますか?っていう質問がありますね。
さっきまで割とフラッターでこういうのだったらいけるよねみたいな話は結構あったんですけど、
逆になんかこういう開発はフラッターはちょっとなーみたいなのとかってあったりするんですかね?
あります?考えてる最中ですか?
例えばTikTokをフラッターで作ってくれって言われたら、
ちょっとえ?って言うかもしれない。
とりあえず僕はちょっと嫌ですって言うかもしれない。
僕ちょっとサーバーを書いてる割合の方が高いんで、
あんま適当なこと言ってたら横やりをあげてほしいんですけど、
序盤で金髪さんがおっしゃってたマテリアルUIベースでウィジェットが組まれてるみたいなところとか、
いってフラッターウェイじゃないけどレールみたいなのがある気がしてて、
そのレールを外れようと思うとちょっとめんどくさいのかなっていう気はなんとなくしてますね。
42:06
なんか一回あったのは、
なんだっけな、
UIの調整でこのウィジェットの位置をこうしたいみたいなやつを頑張ってやった時に、
なんかあれかな、
多分ウィジェットの機能でそれができなくて、
それを実現しようと思うと中身の実装をどうにかいじらなきゃいけなくて、
結局諦めたことがあって、
そういう話になってくると、
多分フラッターに限らずどのフレームワークでもそうだと思うんですけど、
めんどくさいよねっていうのは思ったりしました。
そうですね、TikTokがなんでやったかっていう理由としては、
標準のUIがあまり使えないというか、
結構特殊なUIを自分たちで実装しなくちゃいけないようなパターンだと、
結構そういうのを作っていただけてる方もいるんですけど、
結構難しそうだなという雰囲気がありますね。
逆にその反面、フラッターってマテルデザインベースなので、
例えば社内のデザイナーさんとかと話すときも結構共通認識が取れて、
デザイナーさんもそんなに特殊なUIとかも提案してこないし、
割とその動きっていうのもわかってるので、
割とスムーズにそういう話も進みやすいのかなっていうところが、
僕は結構いい点としてもう1個あったなっていうのは思いましたね。
TikTokはちょっと特殊ですね。
それ以外で扱いにくい面は今のところは感じてないかな。
でもそうですね、ブリッジを描いてしまえば極端な話、結構何でもできるっちゃ何でもできるんで。
例えばなんか、要はUIの部分と、
例えばハードウェアからの要は加速度センサーの値を取りたいみたいなところって、
要件としては全然切り離せると思っていて、
加速度センサーを取るとこって、要はセイフットとコトリのブリッジを描いて、
値を受け取るっていう口を作ってしまえば後は取れるので、
割と気合があれば案外何とかできるかもしれない。
ただTikTokは作りたくない、ちょっと。
フラッターでは。
どちらかというと僕のイメージとしては、
UIの要件でフラッターが難しいかもなって思うところが強いかもしれない。
どちらかというと意外と。
意外とネイティブのSDKとブリッジしなくちゃいけないんですよっていうところは、
どちらかというと自分のイメージとしてはそこは実装すればいいだけだしって思っちゃう。
UI周りとかって結構フラッターで標準で用意されているものを使っているみたいな話があったりして、
45:03
今社内の、知らない程で聞くんですけど、
社内で開発するときにUIを開発しやすいようにするための仕組みとか、
デザイナーさんとの協業とかそういうのってあったりするんですかね。
ダートっていうところから離れちゃうかもしれないんですけど。
アプリ内にありましたよね。
知らない程で聞いていただいたと思いますけど。
そうですね。
一応UIパーツとかは開発環境だけで横になるデバッグモードみたいなので、
一通り実機上で見れるようにしていたりとか、
あとデザイナーとの協業のところは、
基本的にはフラッター前提でデザインを組んでもらって、
フィグマで組んでもらっていると思うんですけど、
そのフィグマを読んで、
この値とこの値というかスタイルみたいなのが多分、
コード上の定義とフィグマ上の定義がシンクするようになっていて、
フィグマをもらってその通りに実装すれば、
基本的には意図したUIになるっていうような感じで協業しているのかなと思いますね。
現状だとNode.jsで言うストーリーブックみたいなやつとかも一応フラッターではあるっぽいけど、
そういうのとかはまだ使っていたりはしないかなという感じですね。
僕の把握している範囲だと。
1個質問が来たやつで、これ僕も気になるところなんですけど、
弊社の場合フロントエンドとバックエンドでダートで統一していて、
一つの言語でっていうところなんですけど、
そこのコードをどれくらい共有できるんですかって質問が来ていて、
実際今ってどうなんですかね。
実際今はどれくらい共有しているのかな。
あんまり共有してないんじゃないかな。
実体としてはリポジトリが分かれているから、
共有は正直してないですよね。
多分共有しているのはGRPCを使っているからそれが入ってくれるダートのコードとか、
多分そこら辺ぐらいで、
自分たちで書いているコードをサーバーサイドとフロントエンドで共有しているってことは、
多分今はまだやってない。
ただ確実にやった方が効率はいいだろうなっていう部分はいっぱいあるので、
そのうちやりたいと僕は思っています。
そうですね。
消費税の計算とか明らかに共有できそうなコードいろいろありますよね。
確かに。
あと個人的には、
でもどうだろうな。
今ちょっと、
でもどうなんだろう。
モノリポリスはちょっとできないのかな。
48:02
どう共有するかみたいなところもめんどくさいっちゃめんどくさい気はしてて、
コンテナレジストリで今多分PUB、
ダートのパッケージをホスティングする仕組みが確かなかった気がするんで、
その辺を考えるとどうしようかなとかも考えつつって感じかな。
あとはうちで言うと、
サーバーサイドフロントエンドっていうわけじゃなくて、
フロントエンドとフロントエンドというか、
一般のユーザーさんが使うお客様アプリっていうのと、
裏側の店舗のスタッフさんが使うスタッフアプリ、
それもそれぞれリポジトリが分かれてしまっていて、
フラッターとフラッターのアプリケーションでリポジトリが分かれている部分は、
もうちょっと近づけられるかもしれない。
それをUIのコンポーネントとかは、
アプリ間で統一みたいなのはもうちょっとできるかもしれないかなとは思いますね。
そこも分かれているので、
たまにこっち片方直したけど、
こっちのアプリに直ってないみたいなのがたまにある。
確かにUIの共有とか普通にやりたいですね。
共有できる部分があるはず。
そうですね。
実際なんかこう…
UI…
あ、いいですよ。
すみません。
コードの共有とかは、
やれたらいいよねみたいな感じのところで、
実際やれてはないけど、
開発その1個のプロジェクトで、
フロントとバックエンドで言語統一したのって、
コンテキストスイッチめっちゃ少ないとか、
1人でもどっちもいけるとか、
そこら辺のメリットのほうが、
コード共有っていうところよりかは、
感じててやったのかなっていうところですね。
それはめっちゃ分かりますね。
コンテキストスイッチまじで必要なくていいですね。
土日にボット書こうと思ってタイプスクリプト書くと、
型アノテーションの位置毎回間違えるっていう。
それが仕事中に起きないっていうのは結構…
地味だけど、それなりに価値のあることかなって気がしますね。
そうですね。
いいか悪いかあれですけど、
どっちかで書いたコードをコピーできるっていうのが嬉しいですね。
そういうこともありますね。
あと5分ぐらいなんで、
もう1個ぐらい話せるといいかなと思うんですけど、
これとかどうか…
フラッタは学ぼうとしてますっていう方で、
バージョン1と2があるけど、
2だけやればいいのかとか、
1と2の差分とか注意点で注意した方がいいとことかあれば、
教えてほしいですみたいなのがあるんですけど。
これは2一択じゃないですかね。
2一択ですね。
2一択だと思います。
これからやるのであれば。
51:01
もう1個ぐらいいけそうな感じで回答が終わってしまった。
そうですね。
事前に来てる質問であるんだろう。
これはサーバーサイドで打取りをするときも
ほっとりロードとかほっとりスタートって恩恵を受けられるんですか?
っていうのを事前にもらってるんですけど、
これは今小川さんが首を振ってましたが。
いやこれ僕は受けてないんだけど、
実は受ける方法があったら教えてほしいです。
僕もあったら知りたいですね。
今のところまるっと再起動するしかないんじゃないかなっていう理解なんですけど。
そうですね。
うちのサーバーは差分あったらまるっと再起動するスクリプトで走らせてますよね基本的に。
要はリロード、要はウォッチャーみたいなのが立ち上がってるんで、
基本的にコードをいじったらそれが動いて反映されるので、
そんなに困ってはいないっちゃ困っていないかなーって感じがしますね。
要はほっとりロードみたいなもんっちゃほっとりロードなんで。
ビルドそんなにストレスになるほど遅くないですよね。
ビルド中か立ち上げ中か。
気にならないですね。
サーバーのコードがもっともっと巨大になったら向けなきゃいけないかもしれないけど、
キンキンは現状の仕組みでそんなに困ってないっていうのが実情なのかなと思いますね。
ありがとうございます。
他にもいくつか質問があるんですけど、ぼちぼちお時間が来てしまったので、
最後クロージングっていうところをさせてもらって終わりにしたいなと思います。
パッと今画面にQRコードを出したんですけど、
今残りの質問とかさらに今回ポッドキャストこの後公開するんですけど、
それをもう一回聞いてもらったりとかして、
質問をもっとしたいとか、ここをもっと深く聞いてみたいとか、
今回の内容じゃなくてもダートとかクラッターに聞いてみたいとか、
10Xについて聞いてみたいとか、いろいろなんでもいいので、
今ここに出している3名はミーティーで随時受け付けてますんで、
ぜひミーティーを入れていただければなと思います。
今日はありがとうございました。
ありがとうございます。
こんなクロージングでいいのか。
ミーティーでお話ししましょう。
それではここまでがイベントの音声になりました。
イベントの最後でも紹介していましたが、
もし10Xで働くことに興味があるな、ちょっと気になるなという方がいたら、
ぜひ今回の登壇者の方のミーティーやツイッターのDMまでお気軽にご連絡いただけますと幸いです。
54:04
それではお聞きいただきありがとうございました。
