#javascript

GitHub issue #492 では、`@redhat-cloud-services/` 配下の多数の npm package で悪意あるリリースが見つかったと報告されています。 影響を受けたのは、`frontend-components` や `insights-client`、`rbac-client` など、かなり広い範囲です。 ここでいう「npm package」は、JavaScript/TypeScript開発で使う部品の配布物のこと。これが汚染されると、使う側のアプリにも被害が波及する可能性があります。 こういう事件の怖さは、自分のコードに何も悪くなくても巻き込まれるところだと思います。 依存パッケージの version 固定、lockfile の確認、セキュリティフィードの監視がかなり重要です。 GitHub の issue #492 では、`@redhat-cloud-services/` スコープに属する複数の npm package で、malicious npm releases（悪意ある npm リリース）が検出されたと報告さ

元記事はX（旧Twitter）の投稿ページだが、今回取得できた本文はエラーメッセージだけだった 表示されているのは、JavaScript無効・対応ブラウザではない・プライバシー系拡張機能の影響など、X側の読み込み失敗に関する案内 つまり「投稿内容そのもの」よりも、「Xのページが正しく開けないときに何が起きるか」を示す状況だった 一見地味だが、SNSやWebサービスがどれだけJavaScriptに依存しているかがよくわかる 個人的には、こういう“中身が見えないエラー画面”こそ、今のWebの弱点を静かに暴いていて面白いと思う 今回の元記事は、X（旧Twitter）の投稿ページへのリンクでした。 ただし、実際に抽出できた本文には投稿の中身はなく、代わりにXのエラーメッセージが表示されています。 内容をざっくり言うと、こんな案内です。 JavaScriptを使えない状態になっている サポートされているブラウザを使ってほしい プライバシー関連の拡張機能が原因かもしれない もう一度試してみてほしい 要するに、Xのページを読み込むための条件が満たされず、表示に失敗したということです。 Jav

AIがプログラマーの仕事をどう変えるのか。この記事は、その話を「フロントエンドがすでに経験したこと」とそっくりだと見ています。 かなり刺激的な主張ですが、正直かなり面白いです。なぜなら、これは単なる「AIすごい／危ない」論ではなく、便利さと引き換えに何が失われるのかを、歴史を使って考えているからです。 AIによるコーディングは、フロントエンドがフレームワークで経験した deskilling（技能の空洞化） に似ている フロントエンドはかつて、HTML/CSS、ブラウザ差、アクセシビリティ、性能などを深く理解する仕事だった でもJavaScript frameworkの普及で、ブラウザを「ただの実行先」とみなし、一般的な開発者でも扱いやすくなった AIも同じように、コードを書く作業を高い抽象度に持ち上げているが、結果が不安定で、抽象化がかなり“漏れる” Stack OverflowやGoogle検索の変化も、「知っている人を少し速くし、知らない人でもそれなりに動くものを作れるようにした」という点で似ている ただし、品質よりも成果が重視されやすい現実

同じようなLLM呼び出しを毎回APIに投げると、当然そのぶん課金される 著者は `llm-cacher` というNode.js向けライブラリを作り、LLMレスポンスのキャッシュを試した ふつうの「完全一致キャッシュ」だけでなく、意味が近いプロンプトをまとめる semantic caching も扱う storageは `memory` / `file` / `SQLite` / `Redis` / `DynamoDB` などを選べる streaming response もキャッシュできるようにしているのが地味にすごい OpenAIやAnthropicのSDKを直接使いながら、フレームワークに寄りかからず導入できるのが売り この記事の出発点はとてもシンプルです。 「AIに同じような質問を何度もしていたら、請求額が思ったより高くなった」 という話。 これ、かなりあるあるだと思います。 開発中って、つい同じプロンプトを何回も投げますよね。文言は少し違っても、やっていることはほぼ同じ。しかもLLMは1回ごとに課金される。つまり、テストを重ねるほどお金が溶けるわけです。 著者は

Freenetは、中央のサーバーに頼らない peer-to-peer（P2P）の分散型プラットフォーム ブラウザ上で動くアプリが、普通のWebサイトのように見えるのが特徴 サーバーやクラウドが不要なので、停止されにくく、追跡されにくい設計をうたっている 開発者は Rust や TypeScript など、見慣れた技術でアプリを作れる 「分散型インターネットの基盤を育てる」ことを、小さなチームと支援者で進めている Freenetは、ひとことで言うと 「中央サーバーのないインターネット上の土台」 を目指すプロジェクトです。 公式サイトでは、通信・コラボレーション・商取引を、いわゆる大手IT企業やクラウド基盤に頼らずに実現する peer-to-peer platform と説明されています。 ここでいう peer-to-peer、略して P2P は、みんなのPCや端末同士が直接つながって動く仕組みのことです。 普段のWebサービスは、だいたい「ユーザー → サーバー → ユーザー」という形ですが、P2Pではその中央のサーバーが主役ではあ

この記事は、npmのサプライチェーン攻撃をネタにした風刺記事 「防ぎようがない」と言う開発者たちを、かなり痛烈に皮肉っている npmは便利な一方で、大量の第三者パッケージに依存しやすいのが弱点 Go、Rust、Web APIs のように、標準機能が強い環境との対比が面白い ただのジョーク記事ではあるけれど、依存関係の管理と安全設計の重要さはかなり本質的 Kevin Patel の記事は、「npmで起きるサプライチェーン攻撃は、もうどうしようもない」という空気を、これでもかというほど皮肉った風刺です。 元記事では、npmレジストリで壊滅的な攻撃が起きて、企業アプリが大量に巻き込まれ、ユーザーデータも漏れた、という設定で話が進みます。 そのうえで、開発者たちが「仕方ないよね」「現代のWeb開発の代償だよ」と、まるで天災みたいに受け止めている様子が描かれます。 これがかなり痛烈です。 というのも、実際のセキュリティ事故では、後から「予防は難しかった」と言われがちですが、この記事はそこに真正面からツッコミを入れているわけです。 **本当に防げなかったのか

元記事では、X（旧Twitter）でページが正しく表示されず、「JavaScriptを有効にして」と案内される画面が出ている さらに「Something went wrong」とも表示され、何らかの読み込みエラーが起きている 画面の案内文からは、JavaScriptが無効、またはプライバシー系の拡張機能が邪魔している可能性が読み取れる これは「Xが壊れた」というより、ブラウザ側の設定や拡張機能との相性問題で起きることが多い 普段あまり意識しないけれど、現代のWebサービスがいかにJavaScript頼みかがよくわかる 今回の元記事は、X（旧Twitter）の投稿ページを開いたときに表示されたエラーメッセージをそのまま示している内容です。 本文を見ると、まず目に入るのは 「JavaScriptを使用できません」 という案内。続けて、**「We’ve detected that JavaScript is disabled in this browser. Please enable JavaScript or switch to a supported b

npmのメンテナーアカウント `atool` が侵害され、317個のパッケージに637個の悪性バージョンが公開された 影響を受けた中には `size-sensor`、`echarts-for-react`、`timeago.js`、そして多数の `@antv` 系パッケージが含まれる 月間ダウンロード数は合計で1500万超とされ、被害範囲がかなり広い ペイロードは認証情報の収集、GitHubへの漏えい、CI/CDへの永続化、AI開発ツールの乗っ取りまでやる しかも、単純な1回きりの攻撃ではなく、複数の経路で再感染しやすい設計になっているのが厄介 semver範囲（`^3.0.6` のような指定）を使っていると、`latest` タグを見ていなくても悪性版を自動で拾う可能性がある SafeDepの記事によると、2026年5月19日、npm のメンテナーアカウント `atool` が侵害されました。 その結果、22分という短時間に、317個のパッケージへ637個の悪性バージョンが一気に公開されたそうです。 ここで地味に

Bunの一部ではなく、Bun本体をRustに書き換えたというかなり大きな話 既存のテストは全プラットフォームで通過 いくつかのmemory leak（メモリリーク）とflaky test（たまに落ちる不安定なテスト）も改善 binary size が3MB〜8MB縮小 benchmarks は同等か、それ以上に高速 そして何より、compiler-assisted toolsでメモリバグを見つけやすくなったのが大きい ただし、まだ最適化とcleanupが残っていて、段階的に進める段階 Bun は、JavaScript や TypeScript を速く動かすための実行環境です。 ざっくり言うと「Node.js の代わりになる、軽くて速い新世代ランタイム」の一角ですね。 今回のPRは、その Bun を Rustで書き換えた というものです。 これ、ひと言で言うと「家の中身をほぼ丸ごと、別の素材で作り直した」くらいの大工事です。普通に考えてかなり無茶です。しかも、ただの実験ではなく、既存のテストを通し、サイズも小

Chrome拡張のManifest V3（MV3）では、Service Workerがいつ死ぬかわからないので、昔のような「メモリに状態を持つ」設計が通用しない そのため、データの正本は chrome.storage.local に置く「disk-first」な作り方が重要になる オフラインや通信断を前提にし、ローカルとGoogle Drive上のデータを安全にマージする必要がある Googleの公式SDKを捨て、native fetch でDrive APIを叩くことで、軽量で速い拡張機能を目指している ただしその代わり、multipart/related のHTTPリクエストを手書きするという、なかなか骨の折れる作業が発生する 制約は面倒だが、うまく付き合うと「ブラウザに自然になじむ」設計に近づく、というのがこの記事の主張 Stack Overflowの記事「Building a Google Drive Sync Engine that Survives MV3 Service Workers」は、Chrome拡張の世界で起きている地味だけ

Genkitに、generate() の流れへ差し込める middleware が追加された 役割は、retry / fallback / 監査ログ / human approval / filesystem access などの共通処理をまとめること middleware は model / tool / generate の3段階に分かれていて、用途ごとに使い分けられる 公式の built-in middleware が `@genkit-ai/middleware` として提供されている 自作 middleware も `generateMiddleware` で作れるので、独自ルールをきれいに再利用しやすい 個人的には、AIアプリの「地味だけど絶対必要な面倒」をフレームワーク側に寄せたのがかなり良いと思う DZoneの記事は、Genkit の新しい middleware システムをかなり実践寄りに紹介しています。ざっくり言うと、LLM に何かをお願いする前後に、横から処理を差し込める仕組みです。 これ、普通のWeb開発でいう Expres