はてなブックマーク

余計なuseMemoを1つ消したらtscが135秒高速化した話 はじめに 大規模なReact + TypeScriptプロジェクトにおいて、無意味なオブジェクトマッピングを行うuseMemoを1つ削除することで、TypeScriptコンパイル時間が146秒から11秒に短縮された(92%改善)事例について報告します。 根本原因の完全な特定には至らなかったものの、実際に発生した現象と問題特定のプロセスを記録します。 本件では、ある程度論理的に原因の当たりをつけたあと、先入観を排して特定するためにAIコーディングエージェントを活用して愚直な二分探索での検証を行わせ、最終的に135秒にも及ぶ遅延の原因となっていた行を特定できました。 問題の発見 大規模なReact + TypeScriptプロジェクトにおいて、yarn typecheckの実行時間が異常に長くなる現象が発生しました。

CursorやClineなどのコーディングエージェントは使っている MCPサーバーも導入したことがある OpenAIなどのLLMをAPI呼び出しを通して使ったこともある といった状況の方が、「でも自分でエージェントを実装するってなると、いまいちピンと来ないんだよな・・・」と思っているときに役に立つ記事になればと思って筆を執りました。 ちょうど1ヶ月ほど前の私が同じ状況で、鳴り物入りでMastraのQuickstartをやってみたものの、自分の頭でエージェントの要件を考えて実装してみると、なんか違うな・・・?と思えてくる。そういう状況でした。 執筆時点でも私個人としてはエージェントの本番投入まではできていないものの、実務および個人開発それぞれでPoCの実装は進めており、周囲(エンジニア・非エンジニア問わず)に対して「エージェントはこれまでのLLM呼び出しとは何が異なるのか」「どのあたりがパワ

Sentryで報告されている以下のIssueの原因を特定し、ソースコードは修正せずに原因を案内せよ @https://example.sentry.io/issues/123456789/?project=9876543&query=&stream_index=10 驚くべきことに、このシンプルなプロンプトだけで十分なのです!複雑な指示や詳細な説明は必要ありません。MCPサーバーがSentryからデータを取得し、AIがコードベースを調査するために必要な情報はすべてこの短いプロンプトに含まれています。これこそがMCPの強みであり、専門的なツールとAIを組み合わせることで、最小限の指示で最大限の効果を得ることができるのです。 Step 3: AIによる調査 プロンプトを送信すると、MCPサーバーがSentryからIssueの情報を取得し、AIがコードベースを調査します。 調査の過程では、以下の

※(注記)ChatGPT o1にテーマを投げて数回やり取りして書き上げてもらいました。趣旨は自分の主張ですが、文章はほぼ全てGPTによるものです。 はじめに エンジニアとして成長し、マネジメントやリーダーシップを発揮するには、何が必要でしょうか。多くの人は「スキル」や「経験値」を思い浮かべるかもしれません。しかし、組織内でより大きな役割や裁量を担う人とそうでない人との違いは、必ずしも能力そのものではありません。 実は、「どれだけ情報を持っているか」が、その人の視座や意思決定力を大きく左右します。 本記事は、まだメンバーレベルの視点に留まっているエンジニアが、殻を破り、マネジメントやリーダーシップへとステップアップするために「情報」に着目することの重要性を解説します。スタートアップでCTOを務めるなかで得た経験を交えながら、なぜ情報が役割や裁量を生み出すのか、その実践的なヒントをお伝えします。 情報

よくある、「LTが3〜7件ほど行われた後、小一時間ほど懇親会が行われるタイプのイベント」の懇親会で起きる個人的あるあるをまとめました。 登壇者に話しかけたいが登壇者が埋まっていて、余った数人の人たちでグループができて変な空気になる ×ばつ3の机に座っているとき、真ん中の2人が左右どっちの会話に属するか悩ましくなる 缶のお酒が余っても、誰も持って帰ってくれない(ので自分が持って帰るから家にあまり飲まない酒が増える) 余ってるといつも「SDGs(Sustainable Drinking Goals)ですからね!」と言って持ち帰るのだが、結果として冷蔵庫に見なれないチューハイが謎に増える。 円になって会話しているとき、1人分常に空けておいてくださいってアナウンスがあっても、実際会話している円に入るの抵抗ある 乾杯でどのグループに缶を持っていくかが運命の分かれ道すぎる 話すとき最初名前を名乗らずにい

概要 4年ほどProductionで使っていたリッチテキストエディタ(Quill on Nuxt.js v2)をTiptap on Next.jsに移行しました。 既存のQuillエディタの使い勝手をTiptapで再現しつつ、改善できるところは改善しつつ、既存の4年分のリッチテキストデータが正しく編集できるようにしなければいけませんでした。 本記事では移行の具体的なプロセスを解説しようと思っていたのですが、リッチテキストエディタは前提知識があまりに多いため、前提となる知識や考え方を解説しているだけでそこそこのボリュームになりました。そこで、一旦考え方や前提知識をまとめた、という体で公開します。 本記事を読んでから各ライブラリのDocsを読んだりカスタマイズを始めたら、少しハードルが下がっていることかと思います。 対象読者の例 リッチテキストエディタに興味がある リッチテキストエディタの開発

export default async function Layout({ children }: { children: ReactNode }) { const supabaseClient = createSupabaseServerComponentClient(); const { data, error } = await supabaseClient.auth.getUser(); if (!data.user) { // This is unreachable because the user is authenticated // But we need to check for it anyway for TypeScript. return redirect('/login'); } else if (error) { return <p>Error: An err

個人開発がおすすめな理由6選 株式会社NoSchool CTO / meijin ※(注記)slidevで発表したスライドをほぼそのまま投稿しています 目次 自己紹介 私が個人開発しているツール 個人開発がおすすめな理由 1)使ってみたい技術を試す場になる 2)不確実性に投資できる 3)作ったことのあるサービスの種類が増える 4)Webサービスの全体感が見える 5)要件定義の経験と視座が得られる 6)汚いコードを書けばどんな目に遭うかわかる まとめ 宣伝 自己紹介 名人 Twitter(X): 名人|マナリンクCTO Zenn: https://zenn.dev/meijin 株式会社NoSchool CTO オンライン家庭教師マナリンク(https://manalink.jp/) 個人開発 テストメーカー(https://test-maker.app/) 好きな言語はTypeScript、好きな

技術記事を書くまでのステップについて順にコツを解説していきます。 特に、技術記事を書きたくてもテーマ選定が難しい、文章が苦手だ、なぜか筆が進まない、うまくまとめられないといった方に読んで欲しい記事です。 一応、エンジニア歴としては数年以内のジュニアレベルの方を想定しています。 以下のように技術記事を企画して、書いて、公開するためのプロセスごとにちょっとしたコツをまとめています。気になるセクションだけでも読んでいただければ幸いです。 テーマを決めよう 対象読者を決めよう 章立てを決めよう 書こう タイトルを決めよう 【余談】技術記事を書く理由とは 筆者について QiitaとZennにて6年以上の記事発信経験があり、 Qiitaでは5,942Contributionsを記録、 Zennでは3,253Likesをいただいています。 テーマを決めよう コツ:テーマのカテゴリによって執筆のポイントや

この記事は個人開発Advent Calendar 2022 1日目の記事です。 2022年6月13日、私が個人開発でリリースしたサービス「テストメーカー」がTwitterで2,000RT、7,600いいね以上の大バズリを記録しました。 「テストメーカー」は穴埋めテストを直感的に作れるツールです。 マウスで穴埋めにしたいテキストを選択して離すと、その部分が穴埋め問題に変わります。 リリース以降、主に全国各地の中学校、高校、大学などの授業で使っていただいたりしながらユーザー数が増えています。 他にも、社会人の方が国家資格を受験するときの受験勉強に使っていただいていることもあります。 ITMediaさんに取材も受けました。 そして、リリースからおよそ1ヶ月が経過した7月に課金機能を実装し、そこから少しずつですが課金してくださるユーザーさんも増え続けています。 本記事では、そんなテストメーカーを支

useAspidaCallerという、REST APIを型安全に呼び出し・状態管理ができるReact Hooksライブラリを書きました。 対象ユーザーはaspidaを使ってREST APIを型安全に実行しており、かつReactを使っている方です。 インストール ※(注記)最初@texmeijin/use-aspida-callerという命名でしたがよりシンプルなものに切り替えました 特長1 ローディングやエラーなどのAPI呼び出しに関連する状態管理ができる useAspidaCallerを使うと、POSTやPUTといった更新系のAPIを型安全に叩けるとともに、ローディングやエラーといった状態管理も宣言的に実装できます。 const Sample = () => { const { put, isPutting, isPutSuccessful, putError, } = useAspidaCal

TypeScriptフルスタックフレームワークのfrourioを使うときの技術選定について考えてみました。 frourioは国産のTypeScriptフレームワークで、aspidaを使ってサーバーサイドからフロントエンドまでシームレスに型安全なREST APIを扱えることを特長としています。yarn create frourio-appコマンドで一瞬で試せるので興味ある方はぜひ動かしてみてください。 一方で、2022年現在では認証周りの実装方法やデプロイに関する知見が少ないのも事実なので、本記事では認証にFirebaseを、デプロイにRailwayを使った技術選定について説明します。 Firebase、Railwayともに非常に簡単に試せるため、個人開発に特におすすめです。 frourioについて frourioは国産のTypeScript製フルスタックWebフレームワークです。 本記事は

awesome-viteという、Vite関連のリポジトリをまとめたリポジトリに、自作のTemplateを掲載していただきました。 掲載してもらったのは以下のTemplateリポジトリです。 Vite、React、TailwindCSSをセットアップしたリポジトリに、Firebase(v9)やESLint、Prettierも設定した、プロトタイピングにうってつけのTemplateリポジトリです。 このリポジトリの内容や、作成した背景、そしてawesome-viteに掲載してもらった方法を順に書き記しておこうと思います。 リポジトリの内容 リポジトリの内容はREADMEに詳しく書いてありますので、ここではかいつまんで説明します。 Vite React React Router TypeScript Tailwind CSS daisyUI Firebase(v9, modular) ESLin

概要 以下のGitHubリポジトリに、Vite + React + TS + vanilla-extract +α が動作するサンプルリポジトリを作った。 本記事では動作させるための設定のポイントや、各利用技術、ライブラリの概要について説明する。 リポジトリ名をplaygroundとしているとおり、今後このリポジトリには色々なライブラリ(react-hook-form, SWRなど)の検証内容を追記していく予定だが、ひとまず環境構築で一段落したので記事を書いた。 動作確認時のバージョン https://github.com/TeXmeijin/vite-react-playground/blob/fbf326e6dba56d0f27a492bfe96906f3f5ab1590/package.json を参照のこと。 Vite Viteは、近年のWebフロントエンド開発における生産性低下に

技術について思っている印象とかを、定期的にまとめておくとあとで見直したときに良い振り返りになるかもしれないなと思ったのでまとめておく。 上記の目的でやるので思い切り主観で書く。 Vue について思うこと composition-api がとてもいい。 composition-api で頑張るなら React 使えよみたいな意見を耳にしたことがあるが、Vue の良いところは、template と style が JS と別個で動くというところだと思っているので、composition-api の前身である Option API が改善したところで、React と比較してどうこうみたいな見解の変化はない。 Vue を使っている限りは、基本的には CSS in JS 戦争に巻き込まれないので平和。 Vue3 をまださほどキャッチアップしていないので適当な意見になるが、SFC の書き方自体が結構変

概要 サーバーサイド TypeScriptのフレームワークで、個人的に有力視している以下の 3 フレームワークを比較します。 FoalTS NestJS frourio 主な比較項目は以下のとおりです。 Controllerの書きやすさ(バリデーション含む) Dependency Injectionの書きやすさ、テストの実装のしやすさ Fastify連携の対応可否 ※(注記)frourio は Next.js をフロントに Integration したフルスタックフレームワークとしての一面がありますが、API 鯖としても便利だと思っているので、本記事は APIの活用にフォーカスして説明していきます。 実装する機能 ユーザーアカウントを作成する APIを実装していきます。 POST /userでユーザー情報を渡して実行するものとして、Controller に UseCase を DI する処理を書い

2020年に公開した記事の内容に、一部deprecatedなライブラリの利用が含まれていましたので更新しました(2021年3月24日)。 また、随時更新を可能にするためにリポジトリを公開しました。ソースを読めば分かる方はこちらをどうぞ! linaria とは Next.js については React の Web アプリケーション向けフレームワークということで知名度が高いと思いますが、 linaria についてはまだ知名度が比較的低いかもしれません。 特筆すべき特徴として、Write CSS in JS, but with zero runtime, CSS is extracted to CSS files during buildが挙げられており、CSS in JS の形式で実装できるものの、Webpack にてビルドした後は独立した CSS ファイルとして書き出されるとのことです。 また

概要 vue/composition-apiの登場によって, Vue.js でも React の Custom Hook のような関数を簡単に作成できるようになりました. 本記事では, vue/composition-apiで作る API 呼び出し用の Hook として「useApi」を紹介しながら, 作成のコツや考え方を説明していきます. また, 最後には useApi 単体でのテストコードも添付しています. Hook のテストコードが気になる方もぜひ読んでください. 対象読者 vue/composition-apiの存在は知っている, または軽く使ったことがある React の Hook の存在は知っている, または軽く使ったことがある useHoge で表される最近のフロントエンドのコードがよくわかっていない といったステータスの方に, useHoge を作成する狙いと compos