← 2026-02-08 の一覧へ戻るホーム
Eigen：ワークスペースの構築

2026/02/03 19:58

Eigen：ワークスペースの構築

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

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Eigen – 2か月の余暇で作られた軽量な Google‑Workspace スタイルのスイート
著者は、メール、ドライブ、ドキュメント（Yjs ベースの共同編集器）、連絡先、およびスタッキー（カンバン）を含む概念実証として Eigen を作成しました。フロントエンドには Vite/React + TypeScript、Bun 上で Elysia ルーティング、TanStack Router & Query、Tailwind CSS、および shadcn/ui が使用されています。
各ユーザーのデータは個別のディレクトリに保存され、その裏側にはユーザーごとの SQLite データベースが構築されています。ファイル自体が内容を保持するため、バックアップはディレクトリをコピーすれば完了します。リアルタイム共同編集は、サーバー上で Yjs ドキュメントをメモリに保持し、WebSocket 経由で同期させ、定期的にディスクへ永続化することで実現しています。
現在の MVP は、予定している機能セットの 5 % 未満しかカバーしていません：エンドツーエンド暗号化、カレンダー、スプレッドシート／プレゼンテーション、チーム／組織サポート、プロトコル互換性（IMAP, CalDAV, WebDAV）、バックアップ／移行ツールが欠如しています。未解決の課題は、ユーザーごとのデータベース手法のスケーリング、セキュリティ向上のため Linux システムユーザーへのマッピング、プラグイン/API アーキテクチャ、および WordPress/Mastodon に似た連合型展開モデルです。
今後のステップとしては、ユーザーフィードバックを収集し範囲を洗練させること、コミュニティレビュー用にコードをオープンソース化すること、セルフホスト版とパブリック SaaS オプションの検討が挙げられます。プロジェクトは https://eigen.is にホストされており、ソースコードはオープンソースライセンス下で公開されています。貢献者やスポンサーは reinder@eigen.is まで連絡してください。

このバージョンはすべての主要ポイントを保持し、根拠のない推測を排除し、曖昧な表現を避けつつ明確で簡潔な概要を提示しています。

本文

昨年の春、私は疑問を抱き始めました。
「自分で Google Workspace を作るとしたらどれほど大変なのだろう？」
米国における状況と大型テック企業が持つ力を考えると、ヨーロッパ風の代替サービスは必要だと感じたのです。

もちろん、自前でワークスペースを構築するのは不可能に思えますが、実際に試してみなければ分かりません。
驚くべきことに、Mark の少し手助けもあり、2 か月間の余暇開発だけで動作確認版を完成させました。メール・ドライブ・ドキュメント・連絡先・カンバンボードが揃い、リアルタイム協働も実装されています。ぜひ eigen.is で試してみてください。

「Eigen」はオランダ語／ドイツ語で「自分の」という意味で、全体像をよく表しています。

アプリ一覧

アプリ機能
**eigenmail**
**eigendrive**
**eigendocs**
**eigencontacts**
**eigenstickies**

すべて最小限ですが、実際に小さなエコシステムを感じられるほど機能します。

背後で起きていること

迅速にプロトタイプを作るために、NPM パッケージとオープンソースライブラリを活用する道を選びました。これは私が普段避けている手法です。ほかのプロジェクトでは自前でコードを書き、既存のものを再発明することが多いからです。公開した数パッケージも完全に依存関係無しです。

スタックは標準的でモダン（少なくともそれを知っている人の話による）です：

  • Bun：サーバランタイム
  • Elysia：サーバルーティング
  • Vite & React + TypeScript：フロントエンド
  • TanStack Router & TanStack Query：ルーティングとデータ取得
  • Tailwind CSS と shadcn/ui：UI

実際に思わぬ構成が完成した点

最初はシンプルなアプローチを取りました。各ユーザーごとにディレクトリを作り、SQLite（ユーザー単位）でメタデータや構造化データを管理し、実際の内容はファイルとして保存します。共有データベースもなく、複雑な中央システムも不要です。

これが最も簡単に動くと思ったため選択しました。

この設計には次のようなメリットがあります：

  • データ分離 – ユーザーごとのデータは完全に隔離されます。
  • バックアップが容易 – ユーザーディレクトリをコピーするだけです。
  • スケーラビリティ – 新規ユーザー追加が既存に影響しません。
  • カスタムストレージ – それぞれのユーザーが独自のストレージバックエンドを持てる可能性があります。

一方で次のような課題も浮上します：

  1. 各ユーザーのデータが分離されている中、どうやって文書共有を行うか？
  2. リアルタイム協働をどのように実装するか？
  3. ファイルベースデータ全体で検索機能をどう提供するか？

docs と stickies のリアルタイム協働は、サーバ側が Yjs ドキュメントをメモリ上に保持しつつ WebSocket で同期させ、定期的にディスクへ書き込む方式です。全員がドキュメントを閉じるとメモリから消えます。

eigen|drive への複数画像アップロード
eigen|docs の共同編集

今後の展望

2か月間の余暇開発で、思ったより多くが動作しました。これに刺激され、さらに進めていきたいと考えています。本当に機能するか、実用的になるかは未知数ですが、探求したいと思います。

現実チェック

私は MVP のほんの一部しか構築していません―おそらく全体の5％以下です。プロダクションレベルに到達するには何年もの作業が必要です。

欠けている要素

  • エンドツーエンド暗号化
  • カレンダー機能
  • スプレッドシート・プレゼンテーション
  • 組織サポート（チーム、共有リソース）
  • 標準クライアントとのプロトコル互換性（IMAP, CalDAV, WebDAV）
  • バックアップと移行ツール

欠けている機能を実装するだけでなく、次のような根本的な問いに答える必要があります：

  1. スケーラビリティ – どこまで拡張しても問題ないか？
  2. シンプルさとセキュリティ – ワークスペースユーザーを Linux システムユーザーと 1:1 にマッピングすることで、より簡素化・安全化できるか？
  3. 拡張性 – プラグイン／API アーキテクチャをどう設計すれば、第三者が深い統合を書けるようにできるか？
  4. デプロイモデル – WordPress ライクなモデル：Eigen をセルフホスト（スタートアップが自前で稼働）しつつ、eigen.is は同じソフトウェアを公開する。理想としては異なるサーバー間でも共有・協働できるようにしたい（Mastodon の分散認証のように）。

初期ステップ

  • フィードバック収集、スコープ精査、最初に構築すべきものを決定
  • コードをオープンソース化し、他者が確認・脆弱性検証・アーキテクチャ検証できるようにする

ご意見とサポートのお願い

皆様からのフィードバックを大変歓迎します。現行構成は最終形ではなく要件でもありません ― 私たちは動くものを目指しています。シンプルで安全なワークスペース、データはすべてユーザーが所有できる環境です。

早期バージョンの試用・貢献・スポンサーをご希望の場合はぜひご連絡ください。
プロジェクトは eigen.is で公開しています。
連絡先：reinder@eigen.is

同じ日のほかのニュース

一覧に戻る →

2026/02/08 6:45

小型 C コンパイラ

## Japanese Translation: Tiny C Compiler（TCC）は、非常に小さな（約100 KBのx86実行ファイル）Cコンパイラであり、1回のステップでコンパイル・アセンブル・リンクを行い、バイトコード層なしでネイティブx86マシンコードを生成します。2.4 GHz Pentium IV上では、Links BrowserテストをGCC（20.0 秒）より約10倍速く実行できます（2.27 秒）。これは別のコンパイルステージが不要であるためです。 TCCはISO C99を完全にサポートし、自身をコンパイルでき、任意のC動的ライブラリを直接リンクすることも可能です。完全なプリプロセッサ、GNUスタイルのアセンブラー構文、オプションのメモリと境界チェック機能、さらにはシェバンベースの「Cスクリプト」まで含まれ、コマンドラインから実行できます。libtccライブラリにより、他のプログラムがTCCをランタイムコード生成のバックエンドとして使用できるようになります。 性能テストはPentium IV上で行われました。新しい測定値（参照1–4）では、モダンハードウェアでも速度向上が継続しています。ドキュメント、メールリストサポート、およびSavannah/GitHubリポジトリは最新情報を提供します。 TCCはGNU Lesser General Public License（LGPL）の下で配布されており、商用利用も許可されています。

2026/02/08 8:23

**良質なコードの静かな終焉**

## Japanese Translation: 著者は中学時代から「Good Code™」―読みやすく、保守しやすく、特定の目的を持って存在するコード――を書き続けることに情熱を注いできました。機能提供に重点を置くソフトウェアエンジニアとして、彼は今日の高速開発環境で良いコードがますます希少になっていると感じています。 同僚の経験はこの状況をよく示しています。外部Linuxカーネル統合システムをCからRustへ書き換えた後、最初のバージョンは機能していたものの読みづらく保守が困難でした。原始的なCロジックを学習した上で再度書き直すと、コードはクリーンになり、自明であり、元のCよりも優れていると言えるようになりました。この経験が著者に品質コードへの熱意を再燃させました。 現在、彼はほとんどの場合初期バージョンを書かず、代わりに「Good Code™」ではなく許容できるものを生成するコーディングエージェントに頼っています。このようなツールへの継続的な依存が個々の行レベルでの品質への注意を薄め、業界実務におけるGood Codeの静かな消滅を招くと彼は恐れています。コード品質が低下すると保守コストや技術的負債が増大し、開発者の生産性、製品の信頼性、そして最終的には企業から提供されるソフトウェアへのユーザーの信頼まで損なわれます。

2026/02/08 2:39

**セクターC：512バイトで実装されたCコンパイラ**

## Japanese Translation: SectorCは、x86‑16アセンブリで完全に書かれたCコンパイラで、単一の512バイトのブートセクタに収まります。Ultra‑compactなトークン化スキーム「Barely C」を使用しており、各スペース区切り語を「メガトークン」とみなし、`atoi()`で識別子をハッシュし64Kテーブルに格納します。変数はこのハッシュを通じてセグメント0x3000に保存されます。最初のBarely C実装は468バイトで、シンボルテーブルなしの再帰下降パーサーでした。バイトスレッド化されたForth風の変種も試みられましたが、サイズをさらに削減することはできませんでした。 最終的なコンパイラはわずか **303 バイト** です。サイズは、フォールスルーロジック、テイルコール、コールフュージョン、`lodsw/stosw`の広範な使用、およびすべてのジャンプオフセットを1バイト内に収めるなどの手法で削減されました。残り約200バイトでBarely Cは完全なCサポートへと拡張されました：ネストされたif/whileブロック、包括的な演算子集合（+, −, *, &, |, ^, <<, >>, ==, !=, <, >, <=, >=）、ハッシュテーブルを介した関数定義と再帰、インライン`asm`ステートメント、および単一行(`//`)と複数行(`/* */`)コメントの両方が実装されました。 コンパイラのランタイムは `rt/` ディレクトリ内の2つのCファイルに分かれています：ライブラリルーチン（多くの場合インラインasmを含む）を持つ `lib.c` とエントリポイントとして機能する `_start.c` です。これらはプログラムソースと結合してからコンパイルされます。記事には、全ブートセクタのBase64文字列、VGAモード0x13hで動くサイン波を描画するデモ、および追加例（`hello.c` はビデオメモリ0xB8000に書き込み、`twinkle.c` はPCスピーカーで「Twinkle Twinkle Little Star」を再生）が含まれています。この作業は、512バイトという一見不可能な目標—完全機能のCコンパイラを実現すること—が、創造的なトークン化、ハッシュ化、および積極的なコードサイズ最適化によって達成できることを示しています。