The PDF library TypeScript deservesParse, modify, sign, and generate PDFs with a modern TypeScript API. The only library with incremental saves that preserve digital signatures.
はじめにDeveloper Experience & Performance チームでエンジニアをしている大矢です。2025年10月30日に、CX(顧客体験)プラットフォーム「KARTE」シリーズのプロダクトのAIネイティブ化に向けた方針「KARTE AI」が発表され、いくつかの機能がベータ版としてリリースされました。 それらの機能の開発を進めるにあたって、2025 年 4 月にKARTE AI Project というプロジェクトが組成され、私は主にプラットフォーム観点での開発を担当してきました。この記事では、プロジェクトをどのように進めたか、アーキテクチャ選択における「集中」の判断、Mastra を使うことの優位性について紹介します。 KARTE AI Project についてプロジェクトが始まる前は、KARTE の Product への AI の組み込みはほとんど進んでいないという状況
Introducing: React Best Practices - VercelWe've encapsulated 10+ years of React and Next.js optimization knowledge into react-best-practices, a structured repository optimized for AI agents and LLMs. vercel.com 40以上のルールが8つのパフォーマンスカテゴリに整理されており、非同期処理の最適化からバンドルサイズ削減、再レンダリング防止まで網羅されています。 「これは便利だ」と思い、個人開発アプリに適用できるか試してみました。 結果、GC 負荷が 22% 増加しました。 この記事では、read-it-later アプリ「Tuck」での実体験をもとに、ベストプラクティスを闇雲に適用する危
All Articles As developers, what we are optimizing for is basically how fast we can show meaningful content to the end user, at an optimal infra cost. When the final UI depends on some data from an external source, how we fetch that data has a direct impact on how soon we are showing the final UI to the user. For the last decade, we have treated data fetching as a specific "moment in time." Part 1
Of the many data points this analysis reports, the most useful metrics to look at are the number of files and types, amount of memory used, and the amount of time spent doing I/O, parsing, and type-checking. If I/O times are high or the number of files/lines are high look at Validating Source Files Inclusion. Deeper Insights with Compiler Traces # If the compiler is spending a lot of time in the p
バックエンド TypeScript を嫌悪する理由はなんですか? TypeScript だからだめで JavaScript はいいのか、JavaScript 自体だめなのか…。 Rails に対抗できるフレームワークの存在がないからなのか…。 Node.js がランタイムとしてだめなのか…。 ちなみに私も最近 TypeScript でバックエンドを書くのは厳しいと思い始めました。 理由は、Rails ほど規約的なフレームワークがないからです。Express や Hono のようなルーティングだけのWebフレームワークは、規模の拡大とともにメンテ不能になりがち。 自分がTypeScriptを嫌悪するのは、まさにTypeScriptでバックエンドを書くのは、すぐにメンテナンス性が低下するのを避けられないと確信しているからです。 その理由は主に、言語機能の限界、"熱狂"、バックエンドフレームワー
本番環境で障害が発生したとき、手がかりになるのは結局ログだけだった——という経験は、多くのエンジニアが持っているのではないでしょうか。ところが、開発中に書き散らしたconsole.logは肝心なときに役に立たないことが多いものです。「ここ通った」「動いた」といったメッセージや、巨大なオブジェクトがそのまま出力されているだけでは、原因特定は困難です。 かといって、本格的なロギングライブラリを導入するのは大げさに感じることもあります。winstonやPinoは高機能ですが、設定項目が多く、エッジ環境では動かなかったり、依存関係が増えたりと、ちょっとしたAPIサーバーには重たい選択肢かもしれません。 本記事では、console.logの限界を整理した上で、実用的なロギング環境の構築方法を紹介します。サンプルコードにはLogTapeを使います。依存ゼロで軽量、Node.js・Deno・Bun・エッ
Building Type-Safe Compound Components02.01.2026 — Design System, API Design, TypeScript, React — 4 min read I think compound components are a really good design-pattern when building component libraries. They give consumers flexibility in how components are composed, without forcing every variation into a single, prop-heavy API. Additionally, they make relationships between components explicit in
ESLint has been the leading web ecosystem linter for a decade. Its dominance is being challenged by new native speed linters such as Biome and Oxlint that implement blazing fast linting using native speed languages. Even TypeScript’s source is being ported from TypeScript to Go. Yet, this Flint project -a new, experimental linter- is implemented in TypeScript rather than Go or Rust. Why does Flint
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く