← 2026-02-19 の一覧へ戻るホーム
PocketBase は FLOSS Fund からの資金提供を受けられなくなりました。

2026/02/19 1:11

PocketBase は FLOSS Fund からの資金提供を受けられなくなりました。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

著者は、規制上の制約とインドからのワイヤートランスファーを好むために最初に断られた後、FLOSS/fund から新しいスポンサーシップを確保しました。この2回目の資金調達で、彼らは12月から PocketBase に専念できるようになり、来年末までに安定版リリースを目指しています。

短期的には、現在の Svelte ベースのアプローチが追加の Node.js ビルドステップを必要とし、ダッシュボードのカスタマイズ（カスタムフィールドや OAuth2 プロバイダーの追加が難しい）に欠けるため、UI の書き直しに注力します。著者は Vue、Preact、Lit、Solid、Alpine、Mithril などいくつかの代替案を評価しましたが、DSL 互換性と将来の保守性には不適切であることが判明しました。

これらの問題に対処するため、Shablon と呼ばれる新しい最小限フレームワーク（依存関係ゼロ、プレーン JavaScript、コンポーネント概念なし）が作成されました。また、フィールド、ボタン、ポップアップ、ドロップダウン、アラートなどの再利用可能要素用 UI キットも開発中です。

具体的な UI の変更が準備できるまで、一時的に機能凍結を実施します；実験的なリレーション・フィルタ解決は、来週または二週間以内に取り除かれる可能性があります。

著者は FLOSS/fund と @zerodha のサポートに感謝しています。

本文

不幸な更新

FLOSS/fund が再度連絡を取ってきましたが、GitHub との提携は規制上の制約によりうまくいきませんでした。現在ではインドからの電信送金（wire transfer）を提案しており、これは広域な跨国紙書類手続きが必要です。彼らへの信頼不足と、個人情報を不安定な共有メールチャネルで扱うインド政府に対する懸念から、進めることに抵抗があります。

その結果、私は FLOSS/fund への応募を撤回し、資金提供を辞退せざるを得ませんでした。
もっと徹底的に調査しておき、発表前に支払を待つべきだったと後悔していますが、今はこの状況です。

現在の状況

  • 主な目標は変わりません：今年中に安定版 PocketBase を公開すること（硬直的な約束はなし）。
  • 新しい UI 機能の大部分はすでに実装済みです。残りのタスクを詳細化する前に、別の箇所に注力する必要があります。
  • もっと明確になり、コミュニティからフィードバックを得る準備が整ったら、新しい発表を行います。

この議論はスパムを防止するためにロックします。参加者とリポジトリのウォッチャーの皆さまもご安心ください。

資金調達の最新情報

昨日、FLOSS/fund が PocketBase のスポンサーとして第二回の資金配分について連絡してきました。
詳細は https://floss.fund/blog/second-tranche-2025-anniversary/ を参照してください。

なお、FLOSS/fund と Zerodha は来年もプログラムを継続します。条件なしのスポンサーシップをお探しなら https://dir.floss.fund/submit にご応募ください。

この資金があれば、12月から少なくとも一年間 PocketBase のみ専念できるようになり、来年末までに安定版リリースを目指します。短期的な焦点は UI を書き直すことです。

UI 再構築

制限事項

  • ダッシュボードのカスタマイズが欠如しています。
  • 既存プラグインはサーバー側フックを使用しており、UI（例：カスタムフィールドオプション、新しい OAuth2 プロバイダー、システムセクション）を拡張する仕組みがありません。

課題

  • SPA ルーターとリアクティビティを外部スクリプトから拡張するのは、Svelte のようなフレームワークでは困難です。Node.js のビルドステップが必要になります。

検討した代替案

  • Vue, Preact, Lit, Solid, Alpine, Mithril など
    • 各々独自 DSL を持ち、プロジェクトの方向性変更や放棄時にメンテナンスが問題になる可能性があります。
  • 好みは Vue または Lit に傾いていますが、安定リリースサイクルを目指すためには依存関係を最小限にしたいと考えています。

現在の実験

私は Shablon (https://github.com/ganigeorgiev/shablon) を試しています：

  • 0 の依存関係
  • 純粋な JavaScript、コンポーネント抽象化はなく、DOM 要素とオプションでのリアクティビティのみ
  • Svelte よりシンプルですが、効率が悪い場合は Vue または Lit に戻ります。

また、再利用可能な要素（フィールド、ボタン、ポップアップ、ドロップダウン、アラートなど）をまとめた PocketBase UI キットも新規に作成し始めました。

次のステップ

  • 来週（あるいは翌週）には、実験的なリレーション‑フィルタサブクエリで最小限の破壊的変更について発表する予定です。
  • プロジェクトはより具体的な UI 更新が整うまで「機能凍結」状態に入ります。
    • 時間をかけて作業しますので、どうぞご辛抱ください。

改めて FLOSS/fund と @zerodha にプロジェクトへの支援ありがとうございます！

同じ日のほかのニュース

一覧に戻る →

2026/02/19 3:37

**「宇宙的にユニークなID」**

## Japanese Translation: > **概要：** > 本文では、真にグローバルなユニーク識別子は衝突を避けるために極めて長くなるべきだと主張しつつ、実際には短いランダムIDや追加の複雑性を伴う決定論的分散アルゴリズムが有効であることを示しています。 > 宇宙の熱死（約 10¹²⁰ 回の演算）に先立つ計算上の物理制限から、絶対安全性を確保するには約 10²⁴０ の可能性―すなわち約 798 ビットの ID 空間が必要です。実務では、122‑bit UUID‑v4 が現実的データサイズに対して天文学的に低い衝突リスクを提供します。 > 中央カウンタや「Dewey」階層方式などの決定論的手法はオブジェクト数に対し対数スケールで拡張されますが、Binary、2‑adic、Token などの代替木構造アプローチは最悪の場合線形増加します。典型的な使用では多くの場合対数スケールで振る舞います。シミュレーションにより、数百万ノードの場合、最大 ID 長は異なる定数を持つ log n で伸びることが示されています。 > この結果から、長いランダム ID（理論上の安全性を確保するためには ≥798 ビット、実務では 122‑bit UUID）が採用されればグローバルな調整を回避し衝突リスクを無視できることが示唆されています。決定論的手法は追加インフラストラクチャを必要とし、ストレージや通信オーバーヘッドを増大させる可能性があります。また、署名・誤り訂正・バージョン管理などの補完策がシステム間でデータ整合性を維持するために必要になる場合もあります。

2026/02/19 6:18

女性用サイズ

## Japanese Translation: ## 要約 この記事は、米国の女性服のサイズシステムが壊れている―欠陥があり、一貫性がなく排他的である―と主張し、多様な体型を反映したカスタマイズ可能なサイズチャートへの移行を訴えている。 「バニティサイズ」が測定値を膨らませる一方、ラベルは変わらずに残っていることから、普遍的な基準が存在しないと指摘する。歴史データでは、標準サイズ8のウエストに合う女性は10 %未満であるにもかかわらず、多くの商品はそのテンプレートを前提として作られている。ブランドごとのチャートは大きく異なり、バスト・ウエスト・ヒップの範囲が混乱しやすい。また、オンライン注文ではサイズ不一致時に返品手数料が発生するケースもある。 このシステムの起源は1940年代に遡り、若い白人女性を基準としていた点でASTMも偏見を認めている。研究では2021‑23年の国立健康統計センター（NCHS）データと、2025年7月時点のマス・マーケット、ファストファッション、高級品を含む主要ブランドのサイズチャート（「レギュラー」と「プラス」サイズのみ）を用いた。著者自身が58件以上の身体測定値を収集しカスタムパターンを縫製した経験も示され、サイズミスマッチが明らかになっている。 この記事は業界に対して、ティーンエイジャーがトゥインからアダルト服へ移行する際に「年齢アウト」させる代わりに柔軟で包摂的なサイズ設定を採用し、返品率の低減・顧客満足度向上、データ駆動型サイズ提供へのシフトを促すべきだと訴えている。

2026/02/19 1:46

テイルスケール・ピアリレーは、現在一般利用可能となりました。

## Japanese Translation: **概要:** Tailscale は Peer Relays を一般公開し、すべてのプラン（無料 tier も含む）で高スループットと低レイテンシを実現できる本番用リレー経路を顧客に提供します。新しいリレーは静的エンドポイント (`--relay-server-static-endpoints`) をサポートし、AWS Network Load Balancer などの制限付きクラウドロードバランサーの背後で実行できるようにすることで、自動検出が失敗した場合にも機能します。 パフォーマンス向上はロック競合の削減と複数インターフェース間での UDP トラフィックの賢い分散によって実現され、クライアントは最適な経路を選択できるようになります。Peer Relays は従来のサブネットルーターに取って代わり、Tailscale SSH と MagicDNS を使用したフルメッシュ展開をプライベートサブネット内でも可能にします。 観測性はさらに強化されます。`tailscaled_peer_relay_forwarded_packets_total` や `tailscaled_peer_relay_forwarded_bytes_total` などのメトリクスが Prometheus 用に公開され、`tailscale ping` コマンドではリレー遅延、信頼性、および到達可能性が表示されます。この機能はすべての Tailscale プランで利用でき、CLI と ACL グラントを介して有効化でき、既存のリレー設定と共存するよう設計されているため、段階的に導入できます。 Peer Relays はエンドツーエンド暗号化、最小権限アクセス、およびシンプルな運用という Tailscale のコア保証を維持しつつ、テイルネット全体でインテリジェントかつレジリエントなパス選択を追加します。