はじめに
DIGGLE エンジニアのitoです。
DIGGLEではたびたびメンバーがカンファレンスに参加することがあります。今回、私は同じ開発チームの同僚のliuさんとともにTSKaigi Kansai 2024に参加しました。
参加した際には感想の記事を作成・公開することが慣習になっているためliuさんとともに参加した感想を書いてみたいと思います。
過去のカンファレンス参加記事はこちらから
TSKaigi Kansai 2024について
TSKaigi Kansai 2024は「2024年5月に東京で開催されたTSKaigi 2024から派生した初の地域型イベントです」とある通り、TSKaigi 2024から始まったカンファレンスです。
以前RubyKaigiに参加させてもらった経験や、フロントエンドでTypeScriptを使っていることから、TypeScriptやフロントエンドにまつわるカンファレンスにオフラインで参加してみたいという気持ちがありました。DIGGLEの開発環境を鑑みてもTSKaigi 2024はマッチしているなと思ったのですが、開催を知ったタイミングが開催当日になってしまったためやむなくオンラインでの参加になりました。
一方でTSKaigi Kansai 2024は幸いカンファレンスの開催を早めに認知することができ、中部在住の私(ito)にとっても行きやすい場所であったため関西在住のメンバーとともに参加することを決めました。
DIGGLEではカンファレンス参加にあたって補助が出る場合があるため、CTOに確認をお願いしました。確認の結果、無事会社の援助を受けて参加できることになりました！
セッション/LTを見た感想
オフラインで参加した私とliuさんで多くのセッション/LTを見ました。
見た発表すべてが面白く、さまざまな知見を与えてくれました。以下では特に気に入った発表をピックアップして感想を書いていきます。
オープニング
主催のかたから「未知の世界に飛び込むのもよし、既知の知識を深めるのもよし。みなさんそれぞれの興味関心に合わせてTSKaigiを楽しんでください」というお話をいただきました。 参加者が充実した一日を過ごせるように導いてくれたオープンニングでした！ 色々勉強になる一日になりそうだと思ってワクワクしました！
(liu)
TypeScriptの型システムは万能機械の夢を見るか？
一番最初に参加したセッションは、エイリアンに講演者が連れ去られる映像からスタートし、エイリアンにさらわれる人のコスプレをした講演者が登場(笑)。チューリングマシンとオートマトンの紹介から入り、TypeScriptの型システムは設計の理論上(*1)、チューリングマシンと同等の計算能力を持つチューリング完全であることと、その強さを紹介する内容でした。このセッションで紹介された型システムだけで作り上げられた色々なプログラムの実例を見て、型安全性を担保すること以外に、TypeScriptで実現できることが実は結構あることを再認識できました。
DIGGLEでは、フロントエンドのTypeScript化に以前から注力しています。まだTypeScriptを使う範囲が限られているのと、計算の部分はRuby on Railsで実装されているバックエンドに任せているため、現時点ではほとんどフロントエンドで扱うデータの型安全性の担保としてのみ使われています。そのため、まだTypeScriptで何かの計算を行う処理はあまりないのですが、講演者の話を聞いて使える武器の選択肢がまたひとつ増えました！
(liu)
*1. 登壇者により、TypeScriptの実際の運用ではいろんな制限があるため、本当にチューリング完全と言えるかどうかもっと検証すべきという論点がのべられていました。
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた
テストコードはみなさんも書いていると思いますが、そのテストコードの品質はカバレッジだけで本当に品質担保ができるのか？という視点を講演者が述べました。
Mutation Testは、コードに何らかのバグを仕込みます。テストコードが、バグの仕込まれたあるコードから返された不正な結果を検知できるかテストします。言い換えると、Mutation Testはテストコードをテストすることができます。テストコードの品質が担保されることで、コードの品質担保にもつながると思いますので、有用でよい内容でした。
便利なMutation Testツールと使い方も紹介されました。「Stryker」というツールはコードの変異とレポートを自動的に作ります！興味ある方は検索してみてください！
DIGGLEみたいな大規模のプロジェクトだと導入するのは大変そうですが、部分的にちょっとずつ導入すればできそうです！
(liu)
型チェック 速度改善 奮闘記
Nxを使って3つのアプリケーションとそれに紐づく100のモジュールをモノリポ化で管理している環境でのTypeScriptの型チェック速度の劣化とその改善のお話でした。
DIGGLE ではpnpm workspaceではあるものの、同様にフロントエンド環境をモノリポで管理するように移り変わっており、今後同様の事象が発生する可能性があり興味を持って発表を聞きました。
特にDIGGLEで利用を始めているzodにおいて「不要なスキーマ定義があると速度低下の原因になる」ことは実装時に意識から外れてしまう部分だと感じたため、レビューの際に気をつけるポイントとして意識する必要がありそうです。
発表の中で型チェックで時間がかかっている場所の調査方法を実演いただき、DIGGLEで実務に落とし込む際にはどのようにすれば実施できるのか？をイメージすることができました(基本的にはアプリケーションのパフォーマンス改善と似たようなプロセスを経るのだなという印象でした)。 また、スライドで表示されていたきれいなグラフはどのように表示しているのか？がとても気になっていたため、speedscopeという Web アプリを利用していることがわかりスッキリしました。
(ito)
コンパウンド戦略を支えるフロントエンド基盤
ビジネスサイドの展望を踏まえて、フロントエンドの基盤を変化させているお話でした。
ビジネスサイドのどういった要望からフロントエンドを垂直分割することになったのかという話は現在のDIGGLEに通ずるところがあり、DIGGLEの今後の展望に対する重要な示唆を得ました。
垂直分割する際に一旦各画面をnpm package化によって分割し、package化作業が完了したのちインフラも分割していくという流れが紹介されており、自身が考えていた進め方に合致していました。 そのため垂直分割するとなった際には自信をもって手法やスコープの話をできそうです。
(ito)
よくできたテンプレート言語として TypeScript + JSX を利用する試み
テンプレート言語が抱える問題点をTypeScript + JSXの組み合わせを活用することによって解消するというお話でした。
DIGGLEではフロントエンドにてReactを使っているため、JSXには馴染みがあり、テンプレート言語として使うとはどういったことなのだろう？という興味で発表を聞いたのですが、JSXにこういった使い方もできるのか！という驚きを受けました。 私的なアプリ開発でjsx-slackを使ったこともあったのですが、内部的にどういったことをしているのかを本発表で知ることができ、とても面白かったです。
メール基盤での活用や複雑なJSON生成で活用できることがわかり、手法の紹介もいただけたためうまく活用できる部分を業務の中で探していきます。
(ito)
フロントエンドの型安全性を高める！Jotaiを用いたフォーム設計の実践
フォームに関してバリデーションを効かせつつ、複雑なフォームを実装するための1つのアイデアとしてJotaiを活用するというお話でした。
発表ではカーテンの注文フォームを具体例として様々な解決策が紹介されていました。DIGGLEでは紹介された例ほど複雑なフォームは現状ない認識でしたが、通貨単位を今後扱っていく方針になった際には、発表の中で紹介されていた「フォームに表示する要素向けの外部atomと、計算などアプリ内で扱うための内部atomの2つのatomを用意して、それぞれを同期させることで実装をきれいにする」という考え方を活用できそうです。
発表を聞くことで、Parse, don't validateの考え方は強力だなということを改めて痛感しました。
(ito)
全体を通して
当日は京都駅で迷子になりながらもなんとか会場の京都市勧業館「みやこめっせ」に到着し、オープニングから参加することができました。
様々なセッション/LTを通して、DIGGLEで現状悩んでいることと似たようなことをみなさんも抱えており、どのようにその悩み事を解消していったのか？という実例を見させていただいたように思います。
知らない世界に飛び込み、さまざまな知見を得ることができたため、得た知見を活かしてDIGGLEのフロントエンド環境向上を心新たに頑張っていきます。
We're hiring!
DIGGLEではともにプロダクトを開発してくれるエンジニアを大募集中です。
少しでも興味があれば、ぜひ下記採用サイトからエントリーください。
カジュアル面談も実施しているので、気軽なお気持ちでご応募いただければと思います！
