piu lentoの日々 (piu lento days)

気付いたら前回から1か月も経っていた・・・ 億劫で本格的な着手は先週だったが、やっぱり手間が掛かって長引いた。約千個のJoplinのノート(画像などを含めたデータ量は約1GB)をZimに移した。

時間と手間は掛かったけど大したことはしておらず、移行スクリプトの作成・既存スクリプトへの機能追加・デバッグ・動作確認程度だ。以下に概要を書く。

ニッチな作業で普遍性がないうえに(手間の関係で)概要しか書けないので他の方の参考には ならないが、自分の整理として書く(詳細が知りたい方はコメントで質問されたい)。

Joplin→Zimへの移行処理

1. Joplin→Zimの変換 (xfr-jop2zim.sh)
   1. 指定したJoplinのノート/ノートブック中のノートに対して次を行う。
   2. 対象のノートがZimに変換済みでない場合、そのノートをZimに変換する。
2. Joplinのリソース(画像など)のZimへの取り込み (att-jop-rsrc.sh)
   1. 指定したZimのノート/ディレクトリ中のノートに対して次を行う。
   2. 対象のノートがJoplinのリソースを参照している場合、そのノート中のJoplinのリソースをZimのリソース(添付ファイル)にする。

1, 2どちらの処理用のスクリプトも これっきり使わない(はずの)ものだが、半ば無駄に高機能化した。例えば、Joplinのリソースを参照しているZimのノートの一覧を出す機能や、ノートブック内の全ノートだけでなく、子ノートブックに対しても再帰的に処理する機能などがある。

そうやって苦労したにも関わらず、もう、処理が2段階だったこと(スクリプトが2個あったこと)を忘れて居た・・・ (まあ、「これっきり使わないもの」ってのは そういうものだ。)

新たにプログラム(スクリプト)を作るのが面倒だし、誤りが多くなりそうなので、既存のもの(機能追加した)を流用・組み合わせた。

書いたあとで気付いたが、上の処理は「流用・組み合わせた」と書いたように、どちらも今まで または前回出来ていたもので、今回は それらを組み合わせただけだ。では何に苦労したかと思い起こすと、ノートの中には特殊なパターンがあって、想定する動作にならない場合があることと、多くのノートに対して 漏れなく2段階の処理をする(しかも結果の確認と処理の修正もする)という純粋な手間だった。

例えば、そもそもJoplinでもZimでも「エクスポート」するだけではリソースのファイルはコピーされず、そのままスマフォに送っても画像などが表示できないことがあるのでコピーし、ノート内のリソースの指定を そのコピーしたものに書き換える。その処理で、リソースの指定(≒ ディレクトリ)には いろいろな種類があり、それらを完全に把握して対応するのが難しいために上記の「特殊なパターン」が多発した。

それらの概要を以下に示す(以前にも書いた気がするが、変更もあるので再度書く)。

移行処理で使って居る処理の概要

1. Joplin(MD) → Zimにエクスポート (jop2zim.sh): 元々使っていたものを若干修正した。
   • 基本的にはJoplinのMDをpandocでZimのフォーマットに変換すれば良いが、pandocだけでは うまく行かないので、以下のようにした。
     1. Joplinからノート(MD)を取得
        • Joplinでエクスポートされるものは不便なので、cliのcatでノートを取得している。
     2. 前処理
        • Zimに変換後では無理な処理をする。
        • Joplinのノートブック→Zimのディレクトリ変換, ノート・ノートブック中の特殊文字の対応, リソースディレクトリ, リソース(画像など)指定, 書式(改行他)の修正・調整, pandocの誤り対応
     3. MD→Zim変換 (pandocを使用)
     4. 後処理
        • 書式(改行, 見出しの下線他)の修正・調整, 僕が変更したZimタグへの対応
     5. 追加情報ファイルの作成
        • Joplinのノート・ノートブック情報, エクスポートした日時, 自動エクスポート(Zim→MD)の可否※などを格納する。
          • ※例えばMDはスマフォに送るので全部のノートを変換する必要はなく(全部送るとデータ量が増大する以外に、同期が頻繁になって電池消費が増える)、その選択に使って居る。
            • 今回は、全部を自動エクスポート不可にし、スマフォに送るものだけ設定変更することにした。
     6. Joplinのノートにエクスポート済みのタグを付ける。 (処理の繰り返しを防ぐため)
   • 備考
     • リソースはJoplinのディレクトリにあるものを参照する。
     • Joplinのcliが不便なので、sqlite3でJoplinのDBにアクセスしてノートやノートブックの情報を取得している。
2. Joplinのリソース(画像など)をZimのリソースにする。 (zim2md.sh -AJI)
   • 下のZim→MDの処理と共通部分が多いので、機能追加した。処理内容は下を参照のこと。
3. Zim → MDにエクスポート(主にスマフォでの閲覧用)時にZimのリソースをMDのリソースにする。 (zim2md.sh): 元々Zim→Joplinにエクスポートするスクリプト(zim2jop.sh)だったものを改造・機能追加した。
   • MD変換はZimのMDエクスポート機能だけでは うまく行かないので、以下のようにした。
     1. 追加情報ファイル(上述)のサポート
        • 例: 自動エクスポート不可の場合は処理しない。
     2. Zimのノートを一時ノートにコピーして前処理
        • MD変換後では無理な処理をする。
        • MD書式(水平線, 箇条書きのインデント, 引用, コードブロックなど)の修正・調整
        • リソース(画像など)の抽出・存在チェックも行う。
     3. Zimで一時ノートをMDにエクスポート
     4. MDを後処理
        • ノートの題の復元(追加), リソース指定(ディレクトリ)の修正
     5. MD(またはZim)にZim・Joplinのリソースをコピー
        • MDと同じディレクトリにリソースディレクトリを作ってコピーする。
        • Zimの埋め込みリソース(MDの"[alt](URL)"(画像でないもの, 先頭の!なし)に対応するもの)はPC内の任意のファイルが指定されるので、MDにコピーするサイズを制限している。
          • 全くコピーしないことも考えたが、多少でもスマフォで見られれば便利と考えた。
     6. MD(またはZimのノート)内のリソース指定(パス)を書き換え
        • Joplinのリソース
        • Zimのリソース

その他の作業

• (延々と)準備・検討・確認, プログラム作成・修正, 動作確認, デバッグ・・・
• ノートの記述、ファイル名、ディレクトリ構造などの修正・調整(修正できない/面倒な/1回しか起こらず、以降も使わない場合)
  • 手抜きだが、もう使わないプログラムを手間を掛けて直すのは馬鹿らしいので。
• Zim内のJoplinのリソース(sym-linkで参照)の無効化 (何らかの手違いで参照されたらエラーで分かるように)
• MD内のJoplinのリソースの削除(不要になったので)

その他

• 元々Evernoteだったノートは、変換を繰り返した(Evernote→Joplin→Zim)ためにフォーマット(特に改行、水平線、箇条書き)が ひどいことになっているが、文章は損なわれていないはずなので、良しとした。
  • 途中でDropbox Paperを使ったり、LinuxではNixnoteを使っていたこともあって、かなり ひどいものがある。下の画像抜けは その関係があるかも知れない。
• Evernoteから移行したものでは画像が なくなっていることが結構あり、自分で処理したとは言え、汎用性のないフォーマット・サービスは良くないと思った。
• スクリプト(特にzim2md.sh)は場当たり的な修正が多くなってしまい、肥大化・複雑化して自分でも全容・詳細が把握できなくなってしまったが、作り直すのは大変なので仕方ない? (どこかの銀行みたいだ・・・)
  • 「＊すれば(手軽に)できそうだ」みたいな始め方が悪かったのは認めるが、そうでもないと始まらなかった。
• 当然ながら、もうJoplinのDB(約170MB)を変更しなくなったので、自動バックアップでのデータ量が減った。変更があると100MB以上(PC全体での量、以下同)だったのが、数十MB(50MB以下の場合も多い)になった。
• 今後、Zimから他に移る可能性があるかも知れないが、その時は汎用的なMDに変換できるので楽そうだ(実際には やっぱり大変だろうｗ)。
• 上で「MDは汎用的」と書いたが、実際には いろいろな種類(流派)があるうえに機能が今ひとつだ。例えば、上・下付きの書式が統一されていない(というか、ない!)。外にも少し(ものすごくではない: 逆に、ものすごい機能はある)凝ったことをしようとすると、非互換かHTMLや外部機能に頼る羽目になって、「何考えてるんだ?」と思う。それが僕がZimを使って居る理由の一つだ。
  • まあ、ZimはZimで欠点(問題点/不具合)は いろいろある・・・ が、機能面では僕には最適・必要充分に近い。

PS. 以前からのTODOが一つ消化できた。が、次にはゴミ箱、タイヤ交換、PC・サーバのOSなどの更新が控えている。そう言えばスマフォの交換(買い替え)もあったな。依然として どれも面倒だｗ

PS2. 本文に書いた「特殊なパターン」に苦労したことで思ったが、僕でさえ そういうことを想定して少しずつ試しに処理して確認・修正しながら進めたのに、ある国の何とかカードの保険証は一気に国全体で始めてしまい、案の定、問題が多発している。「(いいシステムなので)問題は ないと思う(分からん)が、何かあったら現場で頑張れ」のスタンスかと思われるが、そういうのはプロとして恥ずかしい限りだ。まあ、大層な名前や肩書だけど、頭でっかち・口ばっかりでプロじゃないんだろう。

詭弁的な言い訳に、「発生率は極小なので、大きな問題ではない」とかいう、いかにも納得しそうなものがあるが、そういうレアな問題にもシステムの正当性・安全性に疑問を生じさせたり危険性を示すものがある可能性があるので、軽視してはいけない。

そういうことを考慮しない発言をすること、更に、その状況でも なぜか(どういう論理か不明だが)「安心」させて「数」を増やそうと企むことが、指揮者・発注者として失格というか、「無知無能は すっこんでろ!」だ。

そういう連中を弁護する意見に「トラブル0を求めるのは日本人の悪い癖」のようなものがあるが、それとは違う。トラブルを0にすること(無理だ)が目的とか重要なのでなく、起こったトラブルの原因を調べて、例えばシステムに予期せぬ問題がないか調べる・確かめることが重要なのだ。その結果、起こったトラブルが予期されたものであれば仕方ないし、安心できる。

言い換えれば、「問題は必ず起こるが、「だから問題ない」と言ったり、なかったことにするのは間違っている。」だ。

(8/22 4:59 加筆, 6:53 PS2を追加)