現実のアプリケーションで発生するすべてのエラー・例外をResult型に変換するのは非現実的 エラーハンドリングが不要なものはUnexpectedErrorとしてまとめてしまう という現実的な落とし所を提案する記事です。 TypeScriptにResult型を導入したくなる理由 TypeScriptのエラーハンドリングは、try…catch文を使うのが基本です。tryブロック内でthrowされた例外はcatchブロックで捕捉されます。 try…catchによるエラーハンドリングには、以下の問題があります。 例外がthrowされる可能性がある関数かどうかが型シグネチャに表れないため、呼び出し時にtry…catchが必要かどうかわからない exceptionVarの型がunknown（設定によってはany）のため、エラーの種類に応じたハンドリングができない try…catchを細かく切って個別に

自分が使ってるやつを紹介します。 GitHub Star History 指定したGitHubリポジトリのスターの増加数をグラフで見れるサイトです。 たとえば、👇の3つのReactのUIライブラリを例に見てみます。 mui chakra-ui shadcn-ui ▲https://star-history.com/#shadcn-ui/ui&chakra-ui/chakra-ui&mui/material-ui&Date こんな感じで、一目でライブラリの人気度合いをざっくり比較できます。 使い方 テキストボックスに、比較したいライブラリのGitHubリポジトリURLを入力するだけです。 また、「Align timeline」にチェックを入れると、グラフのスタートを揃えれます。 たとえば、Prisma ORMとDrizzle ORMを比較するとPrismaの方が圧倒的に見えますが、スタート

こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの

こんにちは。株式会社プラハCEOの松原です。 弊社は主にスタートアップの新規事業に特化してデザイン・開発をするものづくり集団です。 最近改めて「プラハでエンジニアとして働く上で最低限必要なスキルって何よ？」という話になったのでリスト化してみました。 ついでにそれらにまつわる知識をうまくまとめてくれている情報源を追記しておくので、何かしらの学習素材として使っていただけると幸いです。 前提 前提として弊社が相手にしているスタートアップや新規事業の開発においては とにかく速く仮説検証し続けること が重要なので、継続的に機能改修しやすい柔らかなソフトウェアを作ることに重点が置かれています。他の事業であれば他のスキルが重視されますし、これらが新規事業の開発において絶対の指針だと言うつもりは全くないので 「あ〜新規事業の開発を主に手掛けているプラハっていう特定の会社(N=1)ではこんなスキルが求められ