TSKaigi 2024に協賛・参加してきました

こんにちは、プラットフォーム事業部でマネージャーをしている中村です。 5月11日に中野セントラルパークカンファレンスで開催された「TSKaigi 2024」へ参加してきたので自分が聞いたセッションを抜粋して、レポートとしてお届けしたいと思います。なお、今回OPTiMはコーポレートサイトのお知らせにも掲載しているように、シルバースポンサーとして協賛しています。(お知らせの文章は私が考えました)

www.optim.co.jp

余談ですが最近の業務内容は、チームメンバーへの技術的サポートや1on1、プロダクトの経費・予算管理、新規プロダクトのオーナー、採用関連などエンジニアリングマネージャーっぽいことをしていますが、元はエンジニアで本テックブログにも以下の記事を投稿していました。TypeScriptはプロダクトでの利用もあったり、個人の小さなコードでも書いたりしているので親しみはあります。

閑話休題。

Keynote: What's New in TypeScript

受付を済ませて、いざKeynoteが行われるトラック1の部屋を覗くと満員でした!

現地で「TypeScript歴どのくらいですか?」というラフな挙手制のアンケートをしていましたが、1年未満や1〜3年の人も結構いらっしゃったので経験年数の広さを感じました。

KeynoteはMicrosoftのTypeScript Principal Product ManagerでもあるDaniel Rosenwasser氏によるTypeScriptの次期バージョンである5.5の紹介でした。大まかにはMicrosoft Developer BlogのAnnouncing TypeScript 5.5 Beta に沿った内容でした。個人的にはRegular Expression Syntax Checkingが地味に嬉しかったり。 ブログを執筆した本人の説明に加えてライブコーディングがあると、テキスト以上の情報量があるので改めて同じ内容でも人から直接聞くのは良いなと思いました。

セッション: フロントエンドもバックエンドもインフラも… 全てを TypeScript で統一したらこうなった!

speakerdeck.com

フロントエンド・バックエンド・インフラも全てTypeScriptで統一した開発環境でプロダクト開発を行っている内容のセッションでした。インフラはPulumiをTypeScriptで記述してIaCを実現していました。OPTiMでは以下の記事にもあるように、多くの環境でTerraformを使ってIaCを実現しています。

tech-blog.optim.co.jp

Terraformでは別途HCL(HashiCorp Language)の知識が必要となりますが、PulumiはTypeScriptを知っておけばインフラの記述まで障壁なくできるというのは改めて強いなと思いました。(もちろんインフラを構成するための知識は必要になりますが) ブースにもお邪魔してお話を聞きましたが全ての言語で統一されている恩恵は大きく、チームに加わってからFirst Commitまでの期間がかなり短いとのことでした。

LT: TypescriptでのContextualな構造化ロギングと社内全体への導入!

speakerdeck.com

TypeScript製のマイクロサービスにおいて、どのようにして構造化ログを導入していったのかという内容でした。私が担当しているサービス自体もマイクロサービスで組まれているため、ロギング周りに関するところは頷く内容が多かったです。皆さんのサービスは構造化ロギングできていますでしょうか? すでにあるものに対して導入を進めるにあたって、いきなりロガーを全て入れ替えるという判断をせず、すでにログを出力するために使われている社内の秘伝ライブラリの中身を置き換える判断をしたのは、現実ときちんと向き合って出した結論のように感じました。開発においてすでに存在しているものを改善していく場面はあると思いますが、いかに容易に改善を行い、浸透させていくかというのは難易度の高い課題だと思います。こういった実際にやって、どう工夫したかという話を聞くことができるのもカンファレンスのLTならではの醍醐味だと思いました。

セッション: TypeScriptと型のパフォーマンス

speakerdeck.com

私も過去にあったのですが大きめのUIライブラリなどを入れた時に、やたらVSCodeの型推論が遅いなぁと思う時がありました。このような状態を「型が重い」と定義し、それがどのようなロジックでそうなっているのかというのを調べ、突き止めていった内容でした。 結局のところは型生成にかかるオーダーが型の重さであり、それらは型の大きさではなくGenericsにおける再帰等の深さに依存しているという内容でした。その調査過程でまずはTypeScriptのchekcer.tsを読むところからスタートし、仮定を立ててProfilerを使って計測し、Profilerではわからない型情報を知るために、魔改造したTraceを使って確認していったあたり、しっかりロジカルに追っていっているところに感心しました。

スライドの中にあった「オーバーロード解決は上から順に評価されるため、関数定義の順序によっては大量のType Instantiationが発生するため気をつけた方が良い」という話は、それはそうだけど気が付きにくい内容なので、明日からコードレビューの観点に入れようと思いました。

TypeScriptの型システムの柔軟性があるからこその話でした。

セッション: Prettierの未来を考える

私も使っていましたし、お世話になっているエンジニアも多いであろうFormatterのPrettierのメンテナをされている Sosuke Suzuki 氏のこれからのPrettierがどうあるべきなのだろうかという内容でした。GolangやDenoのようにフレームワークや言語レベルで何も設定を書かずともフォーマットできるコマンドが用意されていますが、Node.jsを使う場合においてはBiomeというアツいツールチェインがRomeからフォークされて登場した今、Prettierと比較して強み・弱みは何だろうというところを冷静に考察するところは、OSSに限らずプロダクトを考える上でも共通な考え方はあるなぁと思いながら聴いていました。

結果的にPrettierはJavaScript製がゆえの柔軟性という特徴を活かし、サポート言語の幅やプラグインの柔軟性の面で価値が提供できそうということでした。その後にお話しされていた「Biomeのような競合相手が今まで登場しなかったため、パフォーマンス等の自分に磨きをかける努力を怠っていたが、登場によって今後はお互いに磨きあってFormatterの品質が改善してくことでしょう」という内容は素敵な内容でしたし、ひょっとしたらBiomeなしにはこのセッションは存在しえなかった可能性もあると考えると感慨深いものでした。

ぜひスピーカーノートがzennに公開されているので一読してみてください。

zenn.dev

そのほか

今回はシルバースポンサーだったので、マイクロファイバークロスをあらかじめ来場者に配布される手提げバックに封入してもらいました。

が、なんと3社マイクロファイバークロスが被る!という内容になってしまったので、ノベルティに関しても今後力を入れていけるよう、社内のデザインチームと考えていきたいと思います。今後のスポンサーにおいてもノベルティを配布する機会はあると思いますので、OPTiMブルーのロゴのものを見かけたらぜひ手に取ってみてください!

最後に

カンファレンスへの参加は久しぶりでしたが、やっぱり直接エンジニアと会って話を聞くというのは楽しいなと思いました。特に実務で使ったり、プロダクトへの実践投入は理想的な状況とは全く異なるので、さまざまな課題が出てきたりします。それらに対してどう取り組んだかというのは、非常にためになる内容です。最近の業務でコードに触れる機会は少なくはなってきていますが、それでも相談を受けることは日常であるため、しっかりこういった場所を使ってキャッチアップしつつ、自分の手も動かさないといけないなと感じました。

OPTiMはTSKaigi以外にもRubyKaigi、Go Conference等でスポンサーをする予定となっておりますので、現地で参加しているOPTiMのエンジニアに出会いましたら、ぜひお声がけください。 またさまざまなカンファレンスにスポンサーをしている通り、多種多様な言語やフレームワークを用いて、第一次産業のDX化に向けて日々現実の課題と向き合っております。そういった難しい実課題を追求して解決していくことに、楽しみを感じる皆さんとお仕事をできることを心待ちにしています。

www.optim.co.jp