"array[i++] = null; は本当に GC を促進するのか — Node.js で実測して確かめる
// packages/react-reconciler/src/ReactFiberConcurrentUpdates.js（L65-L72, 一部抜粋 / 日本語コメントは筆者） while (i < endIndex) { const fiber: Fiber = concurrentQueues[i]; concurrentQueues[i++] = null; // ← これは何のため？ const queue: ConcurrentQueue = concurrentQueues[i]; concurrentQueues[i++] = null; // ... } 値を取り出した直後、わざわざ null を代入しています。コメントには「参照を切らないと GC（ガベージコレクション）に回収されず、メモリリークになる」とあります。 ここで疑問が湧きました。React に限らず、自分
!["array[i++] = null; は本当に GC を促進するのか — Node.js で実測して確かめる](https://cdn-ak-scissors.b.st-hatena.com/image/square/165973aaedb541c55995e1ecb4d2fd46b5fcc61e/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--YxFy_qBy--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%252522array%25255Bi%25252B%25252B%25255D%252520%25253D%252520null%25253B%252520%2525E3%252581%2525AF%2525E6%25259C%2525AC%2525E5%2525BD%252593%2525E3%252581%2525AB%252520GC%252520%2525E3%252582%252592%2525E4%2525BF%252583%2525E9%252580%2525B2%2525E3%252581%252599%2525E3%252582%25258B%2525E3%252581%2525AE%2525E3%252581%25258B%252520%2525E2%252580%252594%252520Node.js%252520%2525E3%252581%2525A7%2525E5%2525AE%25259F%2525E6%2525B8%2525AC%2525E3%252581%252597%2525E3%252581%2525A6%2525E7%2525A2%2525BA%2525E3%252581%25258B%2525E3%252582%252581%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E3%252582%25258F%2525E3%252581%25258B%2525E3%252582%252581%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdGF0aWMuemVubi5zdHVkaW8vdXNlci11cGxvYWQvYXZhdGFyLzI2NDI2MjM3MjguanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png%3F_a%3DBACAGSGT)
UIの面倒、実はDBの問題だった ― Local-First と Instant が示す Web 開発の未来
UIの面倒、実はDBの問題だった ― Local-First と Instant が示す Web 開発の未来 はじめに 2026 年 4 月、開発開始から 4 年を経て Instant が v1.0 をリリースしました。 アナウンスでは、次の 3 つが改めて押し出されています。 Unlimited apps（多テナント Postgres なのでフリープランが止まらない） A sync engine in every app（Figma / Notion / Linear と同じ系譜のリアルタイム同期） Batteries included（Auth / File storage / Streams が同じ DB に同居） The best backend for AI-coded apps そして 1.0 のランディングにて、それと同じくらい強く言い切られているのが次の一文です。 Inst
Wado言語で個人的に気に入っているところ: import, assert, effect - Islands in the byte stream
wado-lang.org Wado言語の開発はずっと続けていて、最近は3-4日くらいで（Wadoの開発のために契約した）Claude Code Max 20x のweekly limitに達してしまってちょっと物足りないくらいです。 まあとにかく、けっこう面白い機能が揃ってきたので紹介します。 imort構文 「このモジュールは標準ライブラリなのかサードパーティなのかローカルなのか、そしてこのライブラリの導入でどういうシンボルが導入されるのか」というのはけっこう言語によって判断が変わるところで、たとえばRustは Cargo.toml に宣言したライブラリを宣言なく使うことができて、しかも wildcard import があるので「どのシンボルがどのライブラリから来ているか」というのがパッとみた感じわかりにくいです。LSPの力を借りればできますが、逆にいえばLSP前提の言語設計といえま
帳票エンジンの会社ですが、4年かけた帳票デザイナーを凍結してAIに全振りしました
デンキヤギでは、2021年から 商用の帳票エンジン（yagisan-reports） を開発しています。 この間に 生成AIにプログラムを書かせることが当たり前 になりました。この流れに追従するため、 帳票エンジンの開発方針を生成AIに全振りして、4年以上取り組んでいた帳票デザイナーの開発を凍結する 決定をしました。 なお、この記事は2年半ぐらい前に書いた記事の続編です。 開発当初（2021年、AI以前）からの構想 yagisan-reportsは最初期から、 帳票テンプレートは人間が読みやすく、手書きできる ことを設計方針の軸の一つにしていました。その結果として、帳票テンプレートはJSXやXAMLなどに似た宣言的なXML形式となっています。 とはいえ、商用製品として売るためには「GUIの帳票デザイナー」が必要不可欠 であるとも考えていて、実際にかなりの初期段階から開発を進めていました。こ
修理費で13万円超えも 折りたたみスマホに「端末保険」が事実上必須といえる理由
折りたたみスマートフォンは国内では大手3キャリアやY!mobile、オープン市場でも販売されており、入手しやすくなった。Galaxy Foldの登場から間もなく7年。3つ折りタイプも登場して話題になりつつあるが、依然として扱いには注意が必要だ。今回は改めて折りたたみスマホを使う上での注意点を整理しよう。 折りたたみスマホで故障しやすいのはメインディスプレイ 折りたたみスマホで、最も故障しやすい部位は展開した「メインディスプレイ」だ。折りたたみ機構に最適化されたディスプレイは、薄型かつ柔軟性を持たせた設計のため、一般的なスマホのディスプレイに比べると耐久性で劣るものが多い。 現在はディスプレイにUTG（Ultra Thin Glass）という薄いガラスを採用し、その上に飛散防止フィルムを貼ったものが主流となっている。ヒンジ部の耐久性強化をはじめ、初期の製品と比較すると現行製品の耐久性は大きく
Matz の Ruby AOT コンパイラ Spinel を試してみました
RubyKaigi 2026 に参加して、Matz のキーノートで Spinel の発表を聞きました。Spinel は Ruby の AOT コンパイラで、Ruby のコードを読み、C のコードを生成し、最後は native binary として実行できる形にします。Ruby を書いている人間としては、「Ruby の AOT コンパイラ」という言葉だけでテンションが上がります。 Ruby はかなり動的な言語でもあります。メソッド呼び出し、クラスの再オープン、メタプログラミング、eval、実行時に変わるオブジェクトの形。普通に考えると、AOT コンパイルとは相性が悪そうに見えます。 それでも Spinel は、Ruby を Prism で parse し、AST をもとに型推論し、C のコードを生成して native binary にします。発表を聞いていて、これは触ってみたいなと思いました
生成AIの正しい障害修正がキッカケで、あなたは顧客の信頼を失うかもしれない
はじめに 生成AIの登場により、コーディングだけでなく障害調査の効率も劇的に改善されました。スタックトレースを貼り付けるだけで原因の仮説が返ってきます。ログを渡せばパターンを読み解いてくれます。以前なら数時間かかっていた調査が、数十分で終わるケースも珍しくありません。 しかし、最近は現場で気になる傾向が増えているように思えます。本番障害対応において、生成AIの提案に従った「正しすぎる修正」が、かえって悪影響を生んでいる ケースです。 この問題の厄介な点は、生成AIが本質的に正しい提案をするからこそ、発生してしまうという点にあります。 何が起きているか：現場の一例 先日、あるDB処理に起因する障害が発生しました。原因は特定の処理パターンにあることが判明し、担当者が生成AIに修正方針を相談しました。 AIは的確でした。該当箇所の問題を正確に分析し、同様の処理パターンが他にも複数存在することを指
Fragments: April 2
As we see LLMs churn out scads of code, folks have increasingly turned to Cognitive Debt as a metaphor for capturing how a team can lose understanding of what a system does. Margaret-Anne Storey thinks a good way of thinking about these problems is to consider three layers of system health: Technical debt lives in code. It accumulates when implementation decisions compromise future changeability.
何かのアピール？ファッション感覚で「ヘルプマーク」を付ける若者たちの“驚きの理由” | FRIDAYデジタル
ライフハックツールではない 赤色に白い十字とハートが施されたデザインのヘルプマークは、援助や配慮を必要としている人が、周囲に知らせるために作製されたマークだ。 だが、このヘルプマークを悪用する人もいる。中国の旅行代理店が中国人観光客向けにヘルプマークを配布し、旅行用のハックツールとして活用しているという噂もあり、本来の利用方法以外の使われ方をしていることが話題になった。 ヘルプマークは特別な許可は不要で、誰でも身に着けることができる。だが、ファッション感覚や、病みアピールのツールとして安易に活用している人もいるようだ。彼らはヘルプマークの本来の意味について知っているのだろうか。 新宿近辺で遊んでいるというAさん（10代女性）はいわゆる“ぴえん系”と呼ばれる属性の女性。多少の区別はあるが、地雷系や量産型とも呼ばれ、彼女らの多くは『病んでいる』ことをステータスとして扱う傾向にある。「常に不安な
ターミナルで動く開発モニタをRustで作った — Ratatuiで実用TUIを作って見えた5つの設計課題とその解き方
イベントループの設計 これらを1つのイベントループでどう協調させるかが最初の課題です。 最初に考えたのは、すべてのデータ取得をtokioのタスクとして非同期に走らせるアプローチです。しかし、ポートスキャンやプロセス一覧の取得はコマンド実行やシステムコール経由であり、非同期化してもほとんどメリットがありません。むしろ、同期的な処理と非同期処理を混在させたイベントループのほうが、実装がシンプルになりました。 let tick_rate = Duration::from_millis(config.general.refresh_rate_ms); let mut last_tick = Instant::now(); loop { // まず現在の状態を描画する terminal.draw(|f| ui::draw(f, &app))?; // 次のtickまで待ちつつ、上限は50msで区切る
GoからBrainfuckへのコンパイラを作った - プログラムモグモグ
go2bfという、Go言語(のサブセット)のソースコードをBrainfuckにコンパイルするコンパイラを作りました。 Goで書かれたソースコードをBrainfuckにコンパイルし、組み込みのインタプリタで実行できます。 Brainfuckはたった8つの命令しか持たないプログラミング言語です。 go2bfは、Go言語の制御構文、関数、再帰、配列、構造体、ポインタといった機能をBrainfuckにコンパイルし、内蔵しているインタープリタで実行します。 github.com Brainfuckの難しさの本質は、ランダムアクセスがないことにあります。 配列アクセスのように、実行時に決定するメモリー位置の値を読み取る仕組みも自分で作らないといけません。 この制約のもとで、配列はもちろん、関数呼び出しのスタックフレームを実現する必要があります。 スタックはガード、値、ゼロの三つのセルを一つのメモリーの
Compression Dictionary Transport 用の Toolkit を公開した | blog.jxck.io
Intro Compression Dictionary Transport(CDT) は、まだ新しいプロトコルのため専用のツールが不足している。 それらを開発し公開したので、紹介する。 CDT-Toolkit CDT は、あらかじめ辞書を作ってクライアントに取得させておき、それを用いて転送を圧縮することができる。 ところが、この辞書を作る汎用的なツールはない。 また CDT で転送するには、作った辞書を用いて圧縮し、専用のヘッダを付ける必要がある。 ところが、この圧縮を行う専用のツールはない。 この 2 つができるツールを Rust で開発し、cdt-toolkit として公開した。 Jxck/cdt-toolkit https://github.com/Jxck/cdt-toolkit crates.io にも公開している。 cdt-toolkit - crates.io: Rust
neovim 0.12からはネイティブの補完で十分そう - Panda Noir
neovim 0.11でLSP補完が有効になった。が、枠線がなかったりプレビューが不足していたり、実用するにはあと一歩足りてない感 があった。 0.11の補完画面 が、0.12でその辺に 強化が入った。 0.12の補完画面 見た目的にも結構変化がわかりやすい。 0.12で入った強化 neovim docsのNews-0.12に書いてあるこの辺りがポイント。 補完アイテムのプレビュー popup menu にボーダー追加 個人的に大きいのは1つ目。プレビュー(枠線部)があることで 圧倒的に使いやすくなった。 2つ目も気分的にはだいぶアガる。枠線が何もないと見づらくて使いづらかったので、けっこう嬉しい。 (他にも色が表示されるようになったという細かい変更もあるが、個人的にはふーんって感じだ) 設定方法 基本はこれでOK。 vim.o.pumborder = 'rounded' -- ポップアッ
Compression Dictionary Transport によるコンテンツ圧縮の最適化 | blog.jxck.io
Intro Compression Dictionary Transport は、圧縮に用いる辞書を HTTP 上で共有するプロトコルであり、2025 年 9 月に RFC 9842 として標準化された。 本サイトの対応を行ったので、方式の概要とデプロイ方法について解説する。 圧縮 圧縮は、基本的に「同じ値が出てきたら、前の値への参照に置き換える」という方式が中心となる。 例えば以下のような HTML を考えよう。 <link rel="author" href="https://jxck.io"> <link rel="canonical" href="https://blog.jxck.io"> 参照する位置とその長さを [n:m] と表すと以下のように置き換えられる。 <link rel="author" href="https://jxck.io"> [0:11]canonical
AIで実装は速くなった。でもチーム開発が逆に難しくなった理由 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先に結論 AIを導入すると、実装スピードは確実に上がります。 ただ、チーム開発で本当に問題になるのは、コードを書く速さではなくコードを理解し、判断を共有する速さです。 今回読んだ2本の記事から得た学びを一言でまとめると、次の3つでした。 仕様書は「ずっと保守する正本」ではなく、「認識を揃えるための起点」として使う AI時代のレビューは、「細かい指摘」より「なぜその実装なのか」を確認する場になる AIが書いたコードをチームの資産にするには、「説明できる状態」を作ることが必要 「AIで実装は速くなったのに、レビューや設計はむしろしんどくなっ
AIコーディング時代に必要なプログラミングスキル - Qiita
「もうプログラミングスキルは不要」勢へ 恐らくそれは「プログラミングスキル」ではないです。 いや単に「プログラミングスキル」という言葉の定義の問題かもしれない。 実際多くの人はPythonの文法、JavaScriptのフレームワーク、SQLのクエリ構文——つまり特定言語に関する文法知識をイメージするんじゃないかと思います。 それ故、コーディングエージェント全盛時代に、文法知識の重要性が相対的に下がる・・・これはその通りかと思います。 じゃあ「プログラミングスキルはもう要らない」のか？ それは完全に誤りです。 自然言語でAIに指示する場合であっても、プログラミング的な思考能力がなければ正しい指示はできません。つまり、自然言語であってもプログラム であり、書き手には「プログラミングスキル」が要ると考えています。 ここでいう「プログラミングスキル」は文法知識ではありません。計算論的思考（Comp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Podroid: Linux containers on Android, no root required
GitHub - hook0/hook0: Open-source webhook server that helps you provide webhooks to your users. It handles for you a great amount of features that are usually tedious to (re)implement.
GitHub - hyperlight-dev/hyperlight-sandbox: A multi-backend sandboxing framework for running untrusted code with controlled host capabilities built on Hyperlight.
GitHub - forrestchang/andrej-karpathy-skills
