nDiki : 公開で作業する

Markdown ノートテキストファイルを rclone で Google ドライブに同期して共有する

Obsidian Publish で「公開で作業」しているように、組織内でもノートを適切な範囲に公開しながら作業したい。

Google ドライブにテキストファイルを置くだけではイケてなくて(断片的なノートテキストファイルの一部を Google ドライブで共有するのをやめた)、Google ドキュメントに貼り付けて共有してみたりもしたけれどそれはそれで手間でイケてなかった(断片的なノートの Google ドキュメント化共有をやめる)。

静的サイト生成して共有できればベストだけれど、保守コストが高いし共有範囲の管理が現実的ではない。うーん、まあやっぱりせめてそのままでもいいから Google ドライブで Markdown ファイルを共有しておくか。内部リンクなど Obsidian 方言であることも許容で。

permalink 維持を前提としたくないので、全文検索できるようにしておくのは必須。 Google ドライブで 拡張子 md の Markdown ファイルを全文検索できるようにするために rclone で同期することにした(Google ドライブで 拡張子 md の Markdown ファイルを全文検索できるように rclone でコピーする)。

[ ノート・日記はテキストファイルに ] [ Markdown で書いているノートを Google ドライブで共有する ] [ 公開で作業する ]

Top of Mind ページと Web ブラウザスタートページを分ける

サイトの訪問者向けの「オーナーの関心事について把握したりサイトを巡回する起点としたりするためのノート」である Top of Mind ノートを Web ブラウザのスタートページにも設定していた(記事)のだけれど、自分向けであるスタートページは別にすることにした。

訪問者向けと自分向けで、書きっぷりが違うのでやはり分けた方がいいなと。

公開で作業する (working in public) という考えから、スタートページも Obsidian Publish サイトに置いておくことにしよ。 Web ブラウザのスタートページは近くにいる人に見られる可能性があるから、もともと他人に見られたくないページを設定しておくのに向かないしね。

[ 公開で作業する ]

ワーキングノートを部門の情報共有ツールに書いてみる

「公開で作業する」を実現するため、部門で使っている Qiita Team 上にワーキングノートを投稿してみることにした。ドキュメントとして残すのが目的ではなく、コミュニケーションの補完として個人の作業ノートを見えるようにしておくのが目的だ。

次のような運用にするつもり。やってみてアレンジする。

• 月曜日にワーキングノートを新規作成する。その週はそのノートを更新する。
• ローカルの Obsidian で元となるノートを新規作成・更新し、1日1度以上目安で Qiita Team の記事を更新する。
• 以下のような事を書く。
  • Top of Mind
  • 気がついたこと
  • 取り組んでいること
  • その他なんでも
• 翌々週に削除する。

Google ドライブでの共有はうまくいかなかった

今まで Markdown で書いているノートを Google ドライブで共有する (Markdown ファイルのままだったり Google ドキュメント化してだったり) のを試みたけれど続かなかった。 Google ドライブはオーナーシップと共有範囲のコントロールをできて良いのだが、記事として気軽に見てもらえるような感じではやはりなかった。

1つのワーキングノートだけに絞る

Obsidian Publish とは違い Qiita Team は記事をローカルファイルと同期できないので、複数のノートを公開・更新していくのは現実的ではない。1つのワーキングノートだけに絞り反映させることにした。

1つのノートを更新していく方法だと変更点が分かりづらいので、だんだん読まれなくなってしまう懸念はあり。

式年遷宮的に運用する

永続的に残ると思うとリンク先の永続性とか気になりだしてしまって更新するのが億劫になる。あくまで作業ノートとして最新のスナップショットだけ共有したい。1つの Qiita Team 記事を更新していくのがシンプルなんだけれど、古い編集履歴を消す機能が無いので1週単位で新しくしてみることにする。

[ 組織内公開ワーキングノート ] [ 公開で作業する ] [ Top of Mind ノート ]

ワーキングノートを部門の情報共有ツールに書いてみた

月曜日に部門の情報共有ツール (Qiita Team) にワーキングノートを新規作成し、その週はそのノートを更新するというのを今週やってみた。

目的に対して

• コミュニケーションの補完という目的をどれぐらい果たせているかはまだ不明(1人から公開初日に良い取り組みだというフィードバックはいただけた)。
• 1つのワーキングノートの公開だけだと「公開で作業する」感はちょっと低め。

運用について

• 毎日1回以上更新は継続できた。
• ローカルのデイリーノートと今回の共有用ワーキングノートの2本立てで書き分けるのに、フリクションが発生する。
• 共有期間を終えたあとのローカルでのアーカイブをどうするかまだ見えていない。

これから

共有するかどうかとは別に、そもそもデイリーノートとワーキングノートを分けない方がいいという気持ちになった。知的作業空間としてはデイリーノート一本化に戻す。作業中に共有・非共有の判断にエネルギーを割かないようにする。

コミュニケーションの補完という目的では、雑感記事をデイリーで情報共有ツールに書いていくのが良さそうだ。

結局行き着くところは社内 Web 日記 (社内 Blog)か。

[ 組織内公開ワーキングノート ] [ 公開で作業する ]

部内 Web 日記を書き始めて約1週間

ワーキングノートを部門の情報共有ツールに書いてみた結果、コミュニケーションの補完という目的で部内 Web 日記として雑感を書くのがいいかなと思ったので、先週の月曜日から Qiita Team に1日1投稿を続けてみている。

「(その日の)トピックス」「(その日に確認し考察した)メトリクス」「雑感」と「(アイデアなどを含むちょっとした)バックログ」が今のところのセクション(該当内容がないセクションはカット)。

情報の鮮度を考えて1週間後に Qiita Team からは削除。ローカルでは非公開のデイリーノートと合わせて Markdown ファイルとして残しつつ、ローカルの他のノートと同じく整理のタイミングでマージされたりしていく想定だ。

また Web 日記を増やしてしまった。まあ Web 日記ドリブンも悪くない。

[ 社内 Blog ] [ 組織内公開ワーキングノート ] [ 公開で作業する ]

Mkdocs Obsidian を試す

Obsidian Publish でノートをインターネット公開しつつ、それとは別に組織内で「公開で作業する」というコンセプトでノートを公開したいと模索している。

Obsidian forum ではいろいろな方法が提案されている。今回は以前使ったことがある静的サイトジェネレータ MkDocs を使った静的サイト生成を試してみることにした。

• Obsidian Mkdocs : A free Publish Alternative WorkFlow

インストール:

 pip3 install --upgrade pip
 pip3 install mkdocs
 pip3 install mkdocs-material
 pip3 install mkdocs-mermaid2-plugin
 pip3 install mkdocs-roamlinks-plugin
 pip3 install obs2mk
 pip3 install mkdocs-awesome-pages-plugin
 pip3 install git+git://github.com/Mara-Li/mkdocs-ezlinks-plugin
 pip3 install mdx_breakless_lists
 pip3 install git+git://github.com/Mara-Li/mkdocs-tooltipster-links-plugin#egg=mkdocs-tooltipster-links-plugin
 pip3 install mkdocs-embed-file-plugins
 pip3 install rich

次に雛形として Mkdocs Obsidian を取得する。

• GitHub - Mara-Li/mkdocs_obsidian_template: The template for mkdocs-obsidian

obs2mk コマンドを使うと Obsidian vault から MkDocs プロジェクトの docs を生成させられる。

 obs2mk --git

そこそこいい感じだけれど出来合いのだと痒いところに手が届かないと思った時にちょっと辛いかなというのが印象かな。開発が止まることもあり得るし頼らない方が良さそう。

濁点のあるノートタイトルは予想通りうまくリンクにならなかった(Unicode 正規化形式の違いのせい)。

「Obsidian vault 内の一部のノートを MkDocs で静的サイト化する」するのではなく「MkDocs で静的サイト化するノートを Obsidian vault 内に置いて一緒に編集する (それらの Markdown ファイルは Obsidian のリンク機能などは使わない)」がいい気がしてきた。

2022年03月27日 追記

Unicode 正規化形式の違いの問題は Obsidian vault を Cryptomator vault の中に置いたことによるもので、 Obsidian + MkDocs で使う上では問題無かった。

• Cryptomator で macFUSE を使うとファイル名が NFD で Unicode 正規化される

[ 組織内公開ワーキングノートサイト ] [ 公開で作業する ]

MkDocs でワーキングノートを GitHub Pages にデプロイし公開する

Markdown で書いているノートを「公開で作業する」というコンセプトで社内で公開するのに、 GitHub Enterprise Server (以下 GHE) の GitHub Pages を使ってみることにした。

静的サイトジェネレータ MkDocs には GitHub Pages にデプロイする機能が入っている。GHE 上のリポジトリに対しても問題なく動いた。

手順1: MkDocs をインストール

 $ pip3 install mkdocs mkdocs-material

手順2: GHE でリポジトリを作成

GHE 上で notes リポジトリを作成する。プライベートでも OK。

手順3: MkDocs プロジェクトを作成する

 $ git clone git@example.com:Naney/notes.git
 $ cd notes
 $ git config user.name 'WATANABE Yoshimasa'
 $ git config user.email naney@example.com

MkDocs 設定ファイルと Markdown ファイルは既存の Obsidian vault の中にそれぞれ置いておき、シンボリックリンクしておくことにする。

 $ ln -s /path/to/vault/Settings/mkdocs.yml

mkdocs.yml 内で以下を指定しておく。

 docs_dir: /path/to/vault/notes

手順4: MkDocs ビルトインサーバでどのようなサイトになるか確認する

 $ mkdocs serve

を実行し、 Web ブラウザで http://127.0.0.1:8000/ に接続しどのように表示するか確認する。

手順5: GitHub Pages にデプロイする

 $ mkdocs gh-deploy

を実行すると gh-pages ブランチ上に静的サイトが生成され、リモートリポジトリに push してくれる。 GHE のリポジトリ側も自動で gh-pages ブランチを GitHub Pages で公開するように設定してくれる。びっくり。 https://example.com/pages/Naney/notes/ が公開 URL になる。

あとは Markdown ファイルを追加・更新・削除したら必要に応じて mkdocs serve で確認しつつ、 mkdocs gh-deploy していけば良い。

やってみると思ったよりお手軽だった。

GitHub Pages は公開

プライベートリポジトリでも GitHub Enterprise Server の GitHub Pages サイトは公開となるので、組織内で限定公開するには境界型セキュリティに頼ることになる。ゼロトラストと考えるなら、漏洩してはならない情報を書かないよう注意して使うべきだ。

[ 組織内公開ワーキングノートサイト ] [ 公開で作業する ]

Logseq でワーキングノートを GitHub Pages にデプロイし公開する

「公開で作業する」というコンセプトで Markdown で書いているノートを先月から MkDocs + GitHub Enterprise Server (以下 GHE) の GitHub Pages で公開してみている(記事)。

一昨日から使い始めたアウトライナー Logseq には graph (ページ群) を静的サイトとしてエクスポートする機能が標準でついている。思考中のメモを公開するのにうってつけそうだ。

MkDocs を使ったドキュメントベースの社内ノートサイトとは別に、アウトラインベースの社内ノートサイトを作ってみた。

手順1: ghp-import をインストール

MkDocs が GitHub Pages へのデプロイで使っている ghp-import をインストールする

 $ pip3 install ghp-import

MkDocs をインストールしていればすでに入っている。

手順2: GHE でリポジトリを作成

GHE 上で graph リポジトリを作成する。プライベートでも OK。

手順3: Git リポジトリをローカルに clone する

Git リポジトリを clone したあと、Logseq graph をエクスポートするディレクトリとして site/ を作っておく。

 $ git clone git@example.com:Naney/graph.git
 $ cd graph
 $ git config user.name 'WATANABE Yoshimasa'
 $ git config user.email naney@example.com
 $ mkdir site

手順4: Logseq で graph をエクスポートする

まずエクスポートするページ毎に [Make it public for publishing] しておくか、設定で [All pages public when publishing] をオンにしておく。

Logseq のメニューから [Export graph] を選び、 Export public pages を指定する。エクスポート先を選択するダイアログで前の手順で作成した site ディレクトリを選び、エクスポートする。

手順5: GitHub Pages にデプロイする

Git リポジトリディレクトリの中で以下を実行しデプロイする。

 $ ghp-import --push --force --no-jekyll site

[ 組織内公開ワーキングノートサイト ] [ 公開で作業する ]

個人の組織内公開ワーキングノートサイト上で参照資料となったノート

組織内で「公開で作業する」というコンセプトで2月から MkDocs + GitHub Enterprise Server の GitHub Pages で組織内公開ワーキングノートサイトを作って使っている。

Markdown 形式で書いている作業中のノートを気軽に共有できるようになったのはやはり良かったかな。

一方9カ月続ける中で他から何度も参照されるような寿命の長いノートが出てきて、ノートへのたどり着きにくさが課題になってきている気はする。過去にシェアした URL を見つけ出して再閲覧するために記憶に頼るところが大きすぎるなと。

参照資料になったノートはきちんと組織の情報共有ツールの方に移しておくべきというのが正論でありつつ、ほとんどそのままにしちゃうんだよね。

組織内で「公開で作業する」というコンセプトの実験を終了する

MkDocs + GitHub Pages で組織内公開ワーキングノートサイトを1年ちょっと続けてきたけれど最近ちょっと保守熱意が下がってきている。

組織内で「公開で作業する」というコンセプトの実験は一度終了することにする。

ふりかえり

• 良かった点
  • コードブロック・Mermaid によるダイアグラム・MathJax での数式・admonitions (call-outs) など表現力のあるノートをさっと書けた。
  • 「ローカルの vaults 内ノート」とローカル内で横断検索できた。
  • 「ローカルの vaults 内ノート」から「組織内公開ワーキングノートサイト上のノート」、「組織内公開ワーキングノートサイト上のノート」から「公開ノートサイト上のノート」と WikiLink 形式で簡単にリンクでき、ハイパーテキストとして書けた。
• 良くなかった点
  • 「公開で作業する」というコンセプトでありつつアピールすることはせず、見てもらいたいノートがある時に関係者に URL をシェアする程度の活動にとどまった。
  • 自分しか編集できないので Google ドキュメント等に比べてコラボレーションしにくかった。
  • 参照資料となったノート (記事) の扱いに困り始めた。