Project ‘ChaosNote’

投稿日時: 投稿者:

 

背景

Jupyterを文書システムとして使っていたら非常に具合が良かったので、Jupyterを元に「汎用ドキュメントシステム(chaosnote)」を作ろうとしている。開発のゴールは、「トラ技の記事を正しく電子書籍に出来る」「それを簡単に書いて共有出来る」ことである。

その第一段として、JupyterをNodeで動かすためのコードを書いている。Pythonのままだと、なんとなく本家に引っぱられてドラスティックな改造が難しくなることと、どうせクライアントはJavascriptで書くわけなので、インピーダンス整合を取っておいた方が楽だろうという観点である。

今のところ、もうちょっとしたらJupyterの基本的な部分は動きそうなので、動くようになったらgithubにでも置こうと思っている。

ゴールについて

ゴールに「トラ技の記事を正しく電子書籍に出来る」と書いているのだが、これについてちょっと説明をする。

「トラ技の記事」には、

  • 文章
  • 数式
  • 計算式
  • 回路図
  • 写真

などが含まれている。

文章はまぁ良いとして、数式は「綺麗な数式」でなければならない。またこれに写真が入るのは、今時の「電子文書」では常識である。この辺は特に説明の必要はないと思う。

問題は「計算式」と「回路図」である。

「計算式」は往々にして「数式」の延長で書かれていて、それに具体的な数字が入ったものが一例として挙げられている。しかし、これがこれだけで終わってしまっては残念である。どういうことかと言えば、ここに「自分の計算」が入れたいと思うわけだ。つまり、「記事」の中に書かれた「計算式」に実際に数値を入れて、自分用の計算をそこでしたいわけだ。そうすれば理解も深まるだろうし、記事を計算ツールとして使うことも出来る。たとえば、「LPFの設計」という記事の中にある計算例に、自分の設計したいLPFのパラメータを入れると各種定数が計算される。そういった使い方がしたいわけだ。

「回路図」も同じで、その回路図をそのままシミュレーションして動かすとか、そのままCADにコピペするとか、そういったことが出来ると嬉しい。

つまり、記事が単なる「電子化された文書」ではなくて、「動く」ものにならないかと。それを実現するにはどうしたら良いかというのが、このプロジェクトの目指すところである。

さらにそれらを「ナレッジ」として「関係者」で共有出来ると嬉しいと思う。そういった「文書」がどんどん書けるようになれば、知識の共有のハードルが下がり、チームのスキルも上げやすくなるのではなかろうか？

Jupyterの良い点

Jupyter notebookは惚れ込むのに十分な価値がある。ただそれは、データ屋さん達が思うものと私が思うものとはちょっと違う。それについて書いておく。

  • 「飛び出す絵本」である
    Jupyterの文書は実際に動く。単なる文書ではなく、そこに書かれたコードは動く。これはまさに「電子書籍」と呼ぶにふさわしい。それと比べたら、今の世間で流通している電子書籍と称するものは、単なる「電子化書籍」に過ぎない
  • インターフェイスが疎結合
    Jupyterが「飛び出す絵本」を実現するためのインターフェイスは、極めて単純である。全ての機能を盛り込んだ巨大なシステムではなく、マイクロカーネルが存在しているだけで、「飛び出す」メカニズムについては、個々のカーネルの機能である
  • ウェブサービスである
    サーバが動いていれば、クライアントはウェブさえ動けばそれで良い。いろいろポータブルだ

Jupyterの問題点

いずれも歴史的経緯や操作性に依る部分があることは理解している。そこは改良のポイントである。

  • 文書を構造的に編集出来ない
    Markdownで文章が書けるのは良いが、編集時に章立てを維持しながらセルを移動させることが出来ない。何度も操作を繰り返せば出来ないわけじゃないが、結構面倒臭い
  • 文書セル(Markdownセル)がMarkdown過ぎる
    Markdownで出来ることは限られているので、もっと自由にいろいろ書きたいのだが、HTMLで直接書くのはあまり具合が良くない。jupyter-wysiwygを使うとそのままのイメージで書けるのだが、これも何か動きが微妙。
  • セルのdefaultがcodeになってしまう
    文章をだらだら書きたい時に、codeになってしまうのは面倒臭い。「直前のセルと同じ」になってりゃいいのに。まぁこれはすぐ直せるだろう。
  • Pythonに依存しすぎ
    まぁこれは出自がそうだからしょうがない。だからこそNodeで書き直しているわけではあるが。図表やグラフ等はPythonを使わなくても済むようになっていると嬉しいんだけどな。
  • ディレクトリ操作に弱い
    文書をディレクトリ間で移動するのは、あまり簡単ではない。これをもっとサクサク出来るようにならんものか。
  • 共有のための仕組みがない
    元々私的な文書のためのシステムなんだろうと思うのだけど、他人と共有するためのメカニズムが全くない。ipynbを直接ハンドリングするしかない。これは例えばグループで何かする時には不便でしょうがない。そもそも、Jupyter単体ではマルチユーザすらない
  • 印刷がpoor
    紙を出そうとすると一苦労。TeXで出してみようとしたら、HTMLで書いたセルはそのまま\verbとか、ふざけんじゃねー。

案

問題点を何とかするための、いくつかの案。

  • セルをネスト可能にしてはどうか？
    セルをネスト可能にして、セルの中に複数のセルを持たせる(<div>で囲う)。移動や複写の時は、「セル単位」とするがそれは「ネストしたセル」も含まれるようにする。
    問題はipynbの互換性。
  • セルの改良
    「文書セル」と言うよりは、MarkdownセルだけじゃなくてAsciiDocセルとか、いろいろ作って追加出来るようにすればいい。今はそれをやりたくても容易ではないので、それ用のインターフェイスをちゃんとする
  • RichFileManagerと組み合わせる
    JupyterLabに期待せず(そもそも方向性が違う)、自前でもっとrichなファイルマネージャ機能を持たせる。雑多なメモも階層で整理しやすくなる
  • 内部に認証システム等を持たせる
    認証システムを持たせたり、権限管理出来るようにする。まぁ今のはpoor過ぎるので、どうせ何とかしないとダメ
  • 印刷はHTMLを基本とする
    今さらTeXでもなかろう。てか、TeXの環境は重過ぎる。また、HTMLをベースにすると決めてしまえば、EPUBに変換することもそれ程大変でもない

方針

開発方針

  • 出来る限りJupyterとの互換性を維持する
    最悪でも、kernelインターフェイスの互換性は維持する。ipynbを拡張する場合でも、後方互換性は維持する
  • 「メモ用紙」メタファーから遠く離れないようにする
    セルやkernelを拡張して「汎用アプリケーションフレームワーク」になることは妨げない。しかし、あまり汎用過ぎて「文書は画面だけで、データは全部データベースにあります」みたいな方向にはしない。backendにデータベースがあるのは構わないが、「紙」の方にもちゃんと記録しておくこと
  • とにもかくにも「大振り」はしない
    どうせ今のところ余暇の個人プロジェクトでしかないので、一度に何でもかんでもしない。当面はJupyterサーバの機能を正しく実装する

ロードマップ

とりあえずやることリスト

  1. Node上のJupyterサーバの実現
  2. 認証権限管理の実装
  3. RichFileManagerとの統合
  4. クライアントの改良

成果物

とりあえずJupyter notebookのMarkdownで書いたセルをマトモに印刷するためのスクリプトを書いてみた。いずれもっとマシにする。

/jupyter-tools

今後の予定としては、

  1. JupyterサーバのAPIドキュメント
  2. jupyter_clientの邦訳
    実は既に手元にある
  3. Jupyterサーバ on Node