2025年9月7日日曜日

「恒星間航行と他の恒星系への植民」（Interstellar travel）
恒星間旅行は現在の推進技術では困難とされますが、核パルス、融合ロケット、ビームソーラセイルなどの理論的な方式が研究されています。数十年〜数世紀の移動を想定した「世代船」も含まれます。Wikipedia+1 The Times
「ダイソン球などのメガ構造物」（Dyson sphere）
恒星を囲ってエネルギーを収集するメガ構造のアイデア。研究によると、ダイソン球は恒星に対して不安定になる可能性が高いですが、特定の二重星系では安定構造になる可能性も示唆されています。Wikipedia Live Science The Sun News.com.au
「世代船（Generation ship）」
宇宙船の中で複数世代にわたって人類が生き続ける移民船の概念で、構想は100年以上前からあり、近年でも詳細な設計案が提案されています。Wikipedia The Guardian
「恒星間アーク船（Interstellar ark）」
Project Orionなどの核パルス推進を用いた巨大船体で、都市規模の人間や文明を長期間保存・輸送できる設計が検討されています。Wikipedia
「O’Neill 円筒型宇宙居住施設（O’Neill cylinder）」
1970年代に提案された、月や小天体の資源を活用して構築する宇宙コロニー構想。対向回転円筒で人工重力を生み出す設計です。Wikipedia
「Breakthrough Starshot」
地上のレーザーでナノスケールの探査機を推進し、数十年以内にアルファ・ケンタウリへ到達しようという壮大なプロジェクトです（構想実現は2030年代以降の見込み）。Wikipedia

Web APIの仕様書には、OpenAPI（旧Swagger）、Postman、Markdownなど複数の形式があります。

Web APIの仕様書には、OpenAPI（旧Swagger）、Postman、Markdownなど複数の形式があります。OpenAPIは業界標準で、YAMLやJSONで記述し、Swagger UIで視覚化も可能。Postmanはコレクション機能でAPIをテスト・整理しやすく、ドキュメント生成も対応。Markdownはシンプルな構造で記述しやすく、専用ツールでモックやサーバーを生成可能。いずれもAPI仕様の明確化やチーム共有、保守性向上に役立ちます。用途に応じて選択するのが効果的です。

🔷 OpenAPI（Swagger）仕様の例

GitHub APIのOpenAPI仕様（Swagger UI）
https://docs.github.com/en/rest
→ GitHubのREST APIがOpenAPI仕様でドキュメント化され、操作しながら確認可能。
Petstoreのデモ（Swagger公式サンプル）
https://petstore.swagger.io/
→ OpenAPI 3.0ベースの代表的なデモ。仕様定義からUI表示まで確認可能。
OpenAPI仕様のYAML例
https://swagger.io/specification/
→ OpenAPI 3.0の構造や記法を学ぶのに最適な公式ドキュメント。

🟠 Postman コレクションの例

Twitter API v2 のPostmanコレクション
https://developer.twitter.com/en/docs/twitter-api/tools-and-libraries/postman
→ 認証付きでTwitter APIをPostmanから試せるように構成済み。
Postman Explore – 公開コレクション一覧
https://www.postman.com/explore
→ 公開されているAPIコレクションを検索・インポートして試せるPostmanの共有ハブ。
Postman Documentation生成例（Stripe）
https://documenter.getpostman.com/view/8920999/SzYXYfmE
→ Postmanのドキュメント機能を使った美しいAPI仕様例。

🔶 Markdown形式のAPIドキュメント例

GitHub Actions API ドキュメント（Markdownベース）
https://docs.github.com/en/actions
→ GitHubはMarkdownで整備された静的ドキュメントとしてAPIを管理。
FastAPIのドキュメント自動生成例（Markdown起点）
https://fastapi.tiangolo.com/
→ PythonのFastAPIではMarkdownコメントからドキュメントを生成可能。
ReDoc によるMarkdownドキュメントのレンダリング例
https://redocly.github.io/redoc/
→ MarkdownやOpenAPIを視覚的に変換するReDocのデモ。

p5 × GLSL-mini DSL (Logical Grid × Dot Size)

GLSL-mini DSL

目的: 論理解像度（Grid）に対してN×N ドットで物理描画。

座標: uv = [-1..1]（上が+／論理解像度基準）
時間: t（秒）
一様: U（U.grid, U.res, U.mouse, U.frame）
戻り: [r,g,b]（0..1）

Program Scale (表示倍率) FPS (描画間隔) Logical Grid (W×H)

Dot Size (1セルの物理ピクセル辺長)

uvを正方形基準に（非正方形Gridでも円が歪まない）

DSLコア V.*: add/sub/mul/div/mod/abs/floor/fract/sin/cos/tan/exp/log/sqrt/step/smoothstep/mix/clamp/min/max/dot/length/normalize/vec2/vec3/vec4/as3/sign/rot2

自作プログラムの最小例

// 同心円の波（論理解像度に依存）
const myProg = (uv, t, U) => {
  const s = V.add(0.5, V.mul(0.5, V.sin(V.sub(V.mul(12, V.length(uv)), V.mul(6, t)))));
  return V.as3(s);
};
// 登録:
examples.Rings2 = myProg; uiRefresh();

マウス座標 U.mouse は uv と同じく [-1..1]（論理解像度基準）。

CC0/MIT。自由に改変・再配布可。

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説（約600字

最小PBR（GGX・直射）— 冒頭解説（約600字）

最小PBR（GGX・直射）— 冒頭解説

このシェーダは、球1個をレイトレし、GGXベースの最小PBRで直射1灯の見え方を計算します。まずカメラからのレイと球の交差を求め、ヒット点の法線 N、視線 V、光線 L を作ります。鏡面はマイクロファセットBRDFで、法線分布は GGX、幾何項 G は Smith の Schlick‑GGX 近似（$k=((r+1)^2)/8$）、フレネル F は Schlick 近似を用います。

$$ F(\theta)=F_0 + (1-F_0)(1-\cos\theta)^5 $$

粗さ $r$ から $\alpha=r^2$ とし、NDF は次式です。

$$ D=\frac{\alpha^2}{\pi\,\big((\mathbf{N}\!\cdot\!\mathbf{H})^2(\alpha^2-1)+1\big)^2} $$

エネルギー保存のため拡散は

$$ k_d=(1-F)(1-\text{metallic}),\qquad f_{\mathrm{diff}}=k_d\,\frac{\text{albedo}}{\pi} $$

とし、金属（metallic=1）では拡散が消えます。最終輝度は

$$ L_o=(f_{\mathrm{diff}}+f_{\mathrm{spec}})\,(\mathbf{N}\!\cdot\!\mathbf{L})\,L_i $$

を一灯ぶん評価し、わずかな環境色を加えてガンマ補正（$1/2.2$）で表示します。パラメータは Blender の Principled と整合し、Base Color→albedo、Metallic、Roughness が同義です。短いコードと基本式だけで「金属らしさ」や「粗さによるハイライトの広がり」を再現でき、さらに IBL、影、ACES トーンマップを加えると実写感が一段と高まります。

https://www.shadertoy.com/view/3cScDD

Web3広告ネットワーク

すでに動いている/資金調達している主な類型と企業

Web3広告ネットワーク（ウォレット/ dApp面の配信）
HypeLab：ウォレットやdApp・NFTマーケットプレイス内に配信、オンチェーン/オフチェーン属性でターゲティング。23年に**$4M**調達。 hypelab.com+1The Block
オンチェーン計測・アトリビューション
Spindl：Web2⇄Web3横断の計測（AppsFlyer連携）/ 22年に**$7M**調達。 Axiosblog.spindl.xyz
Web3オーディエンス構築（アドレス⇄Web2紐付け/拡張）
Addressable：23年に**$7.5M**→24年に累計$13.5M。ウォレットに基づくマーケ堆積を提供。 addressable.io+2addressable.io+2
分散型アドエクスチェンジ/プロトコル
Ambire AdEx：17年からの広告プロトコル（支払いチャネル/スマコン決済）。初期に約**$10–12M**規模の資金調達（ICO）。 GitHubadex.network+1
ユーザー報酬型ブラウザ広告
Brave / BAT：ユーザーが同意して広告を受け取り、BATで報酬。Roadmap 3.0ではオンチェーン連携やクエスト強化。 Brave+1
“クエスト/タスク”型の獲得（オンチェーントライアル=成果）
Galxe、Layer3、Zealy：大規模ユーザー基盤・23–24年に資金調達（Layer3は**$15M Series A**）。広告の代替として成果タスクを組むユースケースが一般化。 galxe.comLayer3PYMNTS.com
アドフラウド対策（オンチェーン検証）
Verasity（Proof-of-Viewでビュー検証、VeraViews提供）。 OKXverasity.io

Web2アドテクと比べた利点（＋理由）

成果の“可監査性”が高い：ミント/スワップ/入金などオンチェーンの最終イベントをコンバージョンにでき、スマコンに記録→レポートの食い違いを縮小。ZKや分散台帳での監査性も研究・実装が進展。 arXiv
同意ベースのID（ウォレット）：**SIWE（ERC-4361）**で署名ログイン→クッキー不要でもセッションと同意管理が可能。スマコンウォレットの署名検証（EIP-1271）にも対応。 Login.xyz+1ethereum.org
自動レベニューシェア/即時決済：支払いをスマートコントラクトで自動化（エスクロー/ストリーミング/上限管理など）。AdEx系は支払いチャネルでマイクロペイメントを大量処理する設計。 GitHub
“ウォレット内”のリーチ：従来のウェブ面では届きにくい**実利用者（保有資産・トランザクション有り）**に直接配信可能。 hypelab.com
ユーザーと利害が一致する設計：Braveのようにユーザーへ還元するモデルが標準機能として存在。 Brave
フラウド耐性の強化余地：ビュー/クリックの“申告値”より、検証可能なイベント（オンチェーン）を課金根拠にできる。PoVのようなビュー真正性検証も登場。 OKX

ただし（現実的な留意点）

到達規模/在庫の成熟度：Web2の巨大在庫・ブランドセーフティ標準（IAS/DoubleVerify等）に比べ、Web3は在庫/測定の標準化が発展途上。Quest型で補完する動きが主流。 Layer3
ID断片化とSybil対策：チェーン/ウォレット跨ぎの重複、スマコンウォレット署名（EIP-1271）対応の実装差など、運用ノウハウが必要。 ethereum.org
Web2側の環境は“まだ動的”：Chromeの3rdパーティCookieは段階的制限の計画が度々変更/遅延。Privacy Sandbox（Attribution Reporting API等）は動き続けており、Web2計測も並行で必要。 Privacy Sandbox+1Wall Street Journal
日本の広告・景品規制/暗号資産規制：表示義務・誇大表現の禁止（景表法/JVCEA指針）に注意。対価や特典（NFT/トークン付与）は景品類上限やリスク表示等の要件を満たす設計が必要。 CAA Japan一般社団法人日本暗号資産取引業協会（JVCEA）t2fifa.or.jp

どう活かすか（実務Tips）

配信：まずはHypeLab等のウォレット面在庫でCPA/CPE試験運用。 hypelab.com
計測：SIWE署名＋campaignIdでクリック識別→オンチェーン成果と1:1照合。Web2計測（AppsFlyer等）とSpindl連携で“Web2→オンチェーン”のラストタッチを補完。 blog.spindl.xyz
不正対策：成果はオンチェーンイベント＋PoV/独自検証の二重化、SC側でcooldown/上限/nonce。 OKX

もともとインターネット自体ディスクロージャーだったはずですけど、マネタイズその他、そうはならなかったですね

もともとネットは「仕様・由来を公開して接続する」文化（RFC/W3C/ブログ）でしたが、収益化とモバイル化で“逆ディスクロージャー”が進みました。要点だけ整理します。

3段階の変遷

開示指向（〜2000）
　公開規格・実名的コミュニティ・リンクで評価＝可視。
不可視化の進行（2000–2010s）
　アドテク/入札/指紋採取、推薦アルゴリズム、アプリ化で“箱化”。
規制主導の再ディスクロージャー（2020s–）
　広告ライブラリ、ステマ規制、C2PA/AIラベリング等で部分的に回帰。

逆転を招いた力学（5つ）

競争優位：データと最適化手法は隠すほど儲かる
プライバシー規制の副作用：同意UIは増えたが実態は見えにくい
プレミアの壁：有料層で情報非対称が拡大
濫用対策：スパム/荒らし対策名目で基準がブラックボックス化
インフラ回収：ログや計測が企業内に囲い込まれた

いま実務でできる「設計の原則」

目的別開示：①推薦理由 ②広告/アフィ関係 ③生成物ラベル（AI/C2PA）
二重ログ：内部監査ログ＋ユーザー向け“ミニ開示ログ”（誰に何が届いたかの要約）
透明性API：出稿・配信・推薦の要約エンドポイントを外部公開
プレミア再設計：有料でも開示文言は無料で誰でも閲覧可
合意UI最適化：1画面1目的・履歴参照・いつでも撤回

進め方（軽量KPI）

可読開示率（開示文を実際に読まれた割合）
関係性明示率（提携/ギフティング表示の網羅度）
推薦理由開示率（リコメンドの“なぜ”を提示した配信の割合）

登録: 投稿 (Atom)

Books pro

2025年9月7日日曜日

Strange Attractor リンク集（サムネ付き）

Strange Attractor リンク集（サムネ付き）

p5.js Webエディタ（SequentialChaos）

attractorsJS（ライブデモ）

attractorsJS（リポジトリ）

DeJong-Attractor（QC20 / リポジトリ）

DeJong-Attractor（QC20 / ライブデモ）

Paul Bourke：Peter de Jong

遠い未来の技術

Web APIの仕様書には、OpenAPI（旧Swagger）、Postman、Markdownなど複数の形式があります。

🔷 OpenAPI（Swagger）仕様の例

🟠 Postman コレクションの例

🔶 Markdown形式のAPIドキュメント例

p5 × GLSL-mini DSL (Logical Grid × Dot Size)

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説（約600字

最小PBR（GGX・直射）— 冒頭解説

Web3広告ネットワーク

すでに動いている/資金調達している主な類型と企業

Web2アドテクと比べた利点（＋理由）

ただし（現実的な留意点）

どう活かすか（実務Tips）

もともとインターネット自体ディスクロージャーだったはずですけど、マネタイズその他、そうはならなかったですね

3段階の変遷

逆転を招いた力学（5つ）

いま実務でできる「設計の原則」

進め方（軽量KPI）

ラベル

ブログアーカイブ

2025年9月7日日曜日

p5.js Webエディタ（SequentialChaos）

attractorsJS（ライブデモ）

attractorsJS（リポジトリ）

DeJong-Attractor（QC20 / リポジトリ）

DeJong-Attractor（QC20 / ライブデモ）

Paul Bourke：Peter de Jong

🔷 OpenAPI（Swagger）仕様の例

🟠 Postman コレクションの例

🔶 Markdown形式のAPIドキュメント例

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説

すでに動いている/資金調達している主な類型と企業

Web2アドテクと比べた利点（＋理由）

ただし（現実的な留意点）

どう活かすか（実務Tips）

3段階の変遷

逆転を招いた力学（5つ）

いま実務でできる「設計の原則」

進め方（軽量KPI）

ラベル

ブログ アーカイブ

ブログアーカイブ