アルゴリズムという言葉がこれほど一般的に使われるようになったのは、いつ頃からだろう。私は情報学専攻の学生だったので、本来の意味でのアルゴリズムについて学んだけれど、今ではもっと広い意味でアルゴリズムという言葉が使われるようになった。 たとえばFacebookやXのフィードとか、YouTubeのリコメンデーションとか、なんだかよく分からないルールでコンテンツが表示される仕組みがある。そのルールのことが昨今ではアルゴリズムと呼ばれている。そして、アルゴリズムは私達にとって最適化されたものであり、社会にとって最善の仕組みであるかのように喧伝されている。 テック企業が自分たちのアルゴリズムについて語る時、私にはどこか責任転嫁のように聞こえる。自分たちがやったんじゃありません、アルゴリズムがやったことです、というような。Xが扇情的なコンテンツを流すのも、YouTubeが陰謀論を広めるのも、それが私達

HTML in Canvas API は WICG の提案段階にある実験的な API です。現時点では Chrome Canary の chrome://flags/#canvas-draw-element フラグを有効にすることで利用できます。 HTML in Canvas API の使用方法 HTML in Canvas API は以下の 3 つの要素で構成されています。 layoutsubtree 属性 drawElementImage() メソッド paint イベント canvas 要素に layoutsubtree 属性を追加することで、canvas 内に描画したい HTML を定義できます。この段階ではまだ canvas 内には描画されません。 <canvas id="canvas" width="400" height="300" layoutsubtree> <div i

はじめに 優秀なエンジニアほど、短命に見える補助スクリプトや一時的な検証ツールに対しても、名付けやUIを雑に扱いません。表面的には過剰品質に見えることがありますが、実際には逆です。そこにこだわるのは余裕があるからではなく、ソフトウェア開発の本当のコストがどこにあるかを知っているからです。 プログラムというものは、最初から思った通りに動くことのほうがむしろ少ないです。多少なりともバグを含み、想定外の入力や環境差、状態遷移の食い違いを抱えています。したがって開発とは、書く作業以上に、疑い、試し、切り分け、直す作業の連続です。 このとき開発者を最も苦しめるのは、計算量の大きさや文法の難しさだけではありません。実際には、理解しづらい名前、迷いやすい操作、責務の見えない構造といった、認知の摩擦こそが調査と修正を大きく妨げます。だから優秀なエンジニアは、短命なコードであっても、その摩擦を最初から減らそ

問いを立てたものたち — OOP (Alan Kay), MVC (Trygve Reenskaug), DDD (Eric Evans), Agile, DRY (Dave Thomas), CQRS (Greg Young), DevOps (Patrick Debois) 2000年、Roy T. Fieldingはカリフォルニア大学アーバイン校に博士論文を提出しました。RESTの原典となったこの論文の第1章、読者が最初に目にするページに、Monty Pythonの『建築家のスケッチ』が引用されています。 すみません…「ナイフ」と言いましたか？ — シティ・ジェント #1 (マイケル・パーリン), 『建築家のスケッチ』 [111] 私は以前、この引用の意味が分かりませんでした。なぜREST論文の序章がMonty Pythonのコメディではじまるのか？ 屠殺場の建築家 屠殺場しか設計し

Roy T. Fielding REST APIは一般に、GET /users/123 のようなリソース指向のURL設計とHTTPメソッドによるCRUD操作のスタイルだと思われていますが、本来はサーバーのレスポンスに含まれるリンクを辿ってアプリケーション状態を遷移させる、ハイパーメディアを基本としたスタイルです。このことは広く誤解されています。 しかしそれを知っている人でもなお、RESTはAPIの設計手法の1つだと誤解しています。RESTはAPI設計についてまとめたものではありません。分散ハイパーメディアシステム——HTTPの設計原理を体系化したものです。 この違いを解説した記事は少ないですが、どうしてこのような誤解が広まったかを考察する記事はもっと少ない。本稿は、RESTがどのようにバズワード化し、広まっていったかについて考察します。 時系列で見るREST前史 1996年 — HTTP/

@h13web です。 昨年の秋に、「グローバル展開にむけたアプリと基盤の再構築」という技術ブログを読みました。日本を代表するテック企業であるメルカリが、グローバル展開のための基盤を刷新したという話です。 この中で語られている「Microservicesの課題」については、思うところがありました。実は弁護士ドットコムでも、かつて似たような体験をしています。モノリスをマイクロサービスに分割するプロジェクトがあり、内部設計より疎結合化が優先され、ドメインを横断するコンテキストが各サービスにコピーされ、開発速度はモノリスのときよりもむしろ落ちました。 その体験を思い起こしながら読み進めるうち、うまく言葉にできない違和感のようなものが湧き上がってきました。記事の筆致は丁寧で、反省の言葉もあります。「今後マイクロサービスを初手で選ぶことは、特別な理由のない限りしないほうがいい」。その率直さには好感を

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに React Compiler を導入したら、フォームが動かなくなった。 watch() で取得した値が更新されない。バリデーションエラーが表示されない。reset() を呼んでもフォームがクリアされない。 自分のコードにバグがあるのかと思って調べた。違った。React Hook Form の設計そのものが、React Compiler の前提と矛盾している。 この記事では、React Compiler が内部で何をしているのかを理解した上で、なぜ React Hook Form をはじめとする既存ライブラリが壊れるのか、その技術的な原因を解説する。 React Compiler は何をしているか React Compiler（babel-plugin-react-compiler）は、コンポーネントや hooks の出力を自動的にメモ化する Babel プラグインだ。 2025

TOPフォーカスZustand、Jotai、Valtioの作者はなぜReact状態管理OSSを3つ開発したのか【フォーカス】 React状態管理ライブラリ開発者 加藤 大志（Daishi Kato） OSS開発者。React状態管理ライブラリ「Zustand」（v3以降）「Jotai」「Valtio」の作者。大手電機メーカーでのリサーチャーを経て、フリーランスエンジニアとして国内外の複数の企業でソフトウェア開発に携わる。OSS活動では主にJavaScriptやReactに関連したライブラリ開発に携わり、現在は特にReactフレームワーク「Waku」に注力。 GitHub X:@dai_shi Zustand Jotai Valtio React開発においてSPA（Single Page Application）を効率的に構築するために、アプリケーション全体の状態をどう管理するか――。すなわ

前の記事[1]では、AIコーディングの原則を整理した。責任は人間が取る、そのためにドキュメントが重要であり、それは人間とAIの両方の架け橋であると書いた。一方で、AIコーディングではコードレビューは不要、あるいは不可能だという声がある[2]。「人間が書いたコードは2025年に死んだ。コードレビューは2026年に死ぬ」と。 「責任は人間が取る」と「コードレビューは不要」は両立するのか。そもそもコードレビューとは何か、何であると思われているのか。この問いを起点に、コードレビューの意味を考えなおし再度位置づけを確認する。 コードレビューはバグ探しではない 多くの開発者がコードレビューの第一目的をバグの発見だと考えている。Bacchelli & Birdの研究[3] [4]では、開発者の44%が欠陥発見を最も重要な動機として挙げた。しかし実際のレビューコメントを分析すると、欠陥に関するものはわずか

Intro Web サービスをデプロイする際に、CA から証明書を取得し HTTPS で暗号化するのが一般的となった。 かつては "SSL 証明書" として、メールでやり取りし有料で購入するのが常識だったが、自動/無料で取得することが増えた。かつては 5~10 年あった有効期限もどんどん短くなり、今では 6 日の証明書も発行されている。 このように、証明書を取り巻く変遷は目覚ましく、それは Web を取り巻く環境の劇的な変化を色濃く反映した結果と言える。 http:// が https:// になった裏で何が起こり、これからどうなっていくのか。まとめていく。 (極力ソースを付記するが、既に消えて WebArchive にも残っていないものも多く、筆者の記憶に頼る情報も多い。) 黎明期 (90 年代後半~2010 年頃) 90 年代の終わり頃、当時は TLS の前身にあたる SSL のデプロ

セマンティックなHTMLで、Webサイトやスマホアプリでよく使用されるさまざまなUIコンポーネントや要素を実装できる超軽量UIライブラリを紹介します。 デザインはシンプルでミニマル！ 依存関係は一切なく、classレスとまではいきませんが、classの使用は最小限で、カスタマイズも非常に簡単です。 Oat UI Oat UI -GitHub Oat UIは、セマンティックなHTMLでWebサイトでよく使用されるUIコンポーネントを実装する超軽量（8Kb）ライブラリです。依存関係は一切なく、フレームワークやビルドといった複雑さは一切不要です。 ライセンスはMITライセンスで、商用プロジェクトでも無料で利用できます。 Oat UI Oat UIの主な特徴は、下記の通り。 超軽量のライブラリ CSS 6Kb、JS 2.2Kbで、まるでオートミールのように軽い 依存関係ゼロ JavaScriptや

2026-03-18 TypeScript 7.0を読み解く「uhyo さんに聞く、ネイティブ化の背景とこれから」

NVIDIAの半導体は既に衛星で使われているが、宇宙にデータセンターを構築するとなると、難易度は大きく異なるという。フアン氏は「言うまでもなく、非常に複雑だ」と述べた。 それでも、AI向けインフラの設置先として宇宙軌道に注目する動きは広がっている。イーロン・マスク氏も、データセンターを宇宙に設置する構想についてたびたび言及している。保有するAI企業とロケット企業を最近統合したことを踏まえれば、その構想も現実味を帯びてきたといえる。 背景には、宇宙ならではの利点がある。例えば、地上のように用途地域や周辺住民への影響を気にする必要がない。太陽光発電を電源として活用できる可能性もあり、設置スペースも広い。ただし、人工衛星の増加に伴い、軌道空間は混雑が進んでいる。 どうする「宇宙は冷えにくい」問題 また、NVIDIAが軌道上AIデータセンター向けコンピュータ「Space-1 Vera Rubin

こんにちは、Jotai作者です。 だいぶ前のことですが、signals について React 文脈で思うことを英語で書いた記事があります。 関連して、以前こんな記事も書いています。 はじめに signals という概念は以前からありますが、Web フロントエンドでは今でもたびたび話題になります。 React 文脈でも、signals をどう捉えるかという話は何度も出てきます。 自分としては、signals には少なくとも 2 つの側面があると思っています。 reactive primitives bypassing diffing この記事では、この 2 つについて書きます。 Reactive primitives React はもともと reactive です。 state が変われば再レンダーされます。 useState でも reactive primitive 的なものは作れます。

はじめに 単一責務の原則(SRP)は、SOLIDの中でも最も有名でありながら、最も誤解されやすい原則の一つです。名前だけ見ると、いかにも分かりやすそうです。単一責務という四文字は、いかにも「一つのことだけをやれ」と言っているように見えます。ところが現場では、この原則ほど人によって解釈がぶれるものもあまりありません。 ある人は、SRPを「一つのクラスは一つのことだけをするべきだ」と理解します。ある人は「変更理由が一つであるべきだ」と理解します。さらにある人は「一つの関係者にだけ責任を負うべきだ」と理解します。どれも全くの外れではないのですが、どれか一つだけを掴むと、すぐに話が崩れます。ここに、分かりやすそうで分かりにくいという、この原則特有の厄介さがあります。 しかもSRPは、コードの見た目だけでは判断できません。短くて綺麗なクラスがこの原則を守っているとは限りませんし、少し大きめのクラスで

https://github.com/xin-chao/nguyen-oi プロンプトを書き換えると好きな人格にできます🤣 ブコメの生成過程が確認できます🤣 https://github.com/xin-chao/nguyen-oi/actions Gemini APIの無料枠が少なくGitHub Actionsの無料枠が月2000分のため、0時から7時まで就寝してます💤 イラン戦争の関係でfree tierだと503でやすいかも gemini-3.1-flash-lite-previewは一日500回無料だからオススメ https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-flash-lite/ Google AI Proに課金してるから月$10ドルまでは有料枠でもお金か

宣言的UIとは何か、皆さんは答えられるでしょうか。 「あーあの、DOM更新を直接プログラムに書くんじゃなくて、JSXとかであるべき状態を宣言したらライブラリが自動的に差分適用とかでDOMを更新してくれるやつでしょ？」 もちろん、このような答えは間違いではありません。しかし、特にAsync Reactの時代においては、Reactの考えはさらに先を行っているようです。 究極的には、宣言的UIは、やりたいことをロジックとして記述するだけで、具体的なことや細かい最適化はよしなにやってくれるものだという考えが伝わってきます。上述のようなDOMの更新の話はその一例にすぎません。 やりたいこと: 特定の形のDOMを画面に表示したい。 具体的なこと: Reactランタイムがコンポーネントツリーを実行してDOMを更新する。 最適化: DOMをいい感じに差分更新する。 また、useStateなどといったステー