Qiita:Team で PlantUML を使ってダイアグラムを書くのにまず手元で編集したいと思い、 Visual Studio Code (VS Code) に PlantUML 拡張を入れた。
ext install plantuml
で拡張をインストール。
Mac (macOS) では Graphviz (それに必要な Java ランタイム)も入れておく。
brew cask install java brew install graphviz
これで Alt-D で PlantUML プレビューができるようになる。
在宅勤務の小物を無印良品 ポリプロピレンメイクボックスにまとめたのいい感じだ。家での朝の仕事の準備がだいぶスムーズになった。座卓のそばに置いておくことで、スマートフォン2台とヘッドセット置き場になるし。
Mac の「プレビュー」アプリケーションで PDF ファイルに署名できそうと思ったらできた。 Mac のカメラで手書き署名をキャプチャし、さくっと PDF ファイルに追加できるのね。
使い始め初日に専用アプリケーションで以下のように割り当てた。
しばらく使ってみたところ音量変更の方をよく使うし、2段階音量を変化させるのに2秒間長押しを2回というのがまどろっこしいしで、ダブルタップと操作を入れ替えてみることにした。
これでどうかな。
さらにしばらく使ってみたところ音量変更はあまりしなくなった。ダブルタップで再生関連をコントロールする方が直感的だったので戻した。
[ WFH 2020 52回目 ]
ローカルで書いている断片的なノートテキストファイルの一部について、そのままの形でも組織内で見られるよう共有しておけば誰かの役に立つかなと思って1月下旬から Google ドライブ上に同期しておいてみたのだけれど、やっぱりやめることにした。
Google ドライブに Markdown 形式のテキストファイルを置いておいても、やはり Markedown プレビューアーが無いと見にくいのが理由の1つ。そして断片的なノートは「柔軟なハイパーリンク記述」「軽快なブラウズ」「高速な検索」が可能な環境ではないと活用しにくく Google ドライブにテキストファイルを置くだけではイケていなかったというのがもう1つの理由だ。
ローカルのテキストファイルでノート管理するスタイルのまま、同期だけで共有でき共有範囲の管理も Google ドライブ上で済ませられたので、お手軽ではあったんだけれどね。
[ ノート・日記はテキストファイルに ]
「タブでエディタの編集画面を切り替える使い方」は見比べながら編集しにくいのであまりしていない。画面分割の方が好き。
なので iA Writer for Mac も複数ウインドウで使ってきた。でもオーガナイザー・ファイルリスト・エディタ・プレビューと横4ペインだと幅をとるので、複数開くのけっこう厳しかったりする。複数タブを使った方が良いのではと思えてきた。ちょっとタブってみる。
(画像は https://1writerapp.com/ より)
いまノートテキストファイルの閲覧・編集は Mac と Android デバイスではライティングアプリ iA Writer を主に使っている。iPhone にも iA Writer はインストールしてあるのだけれど不便でほとんど使っていない。 iOS 11 に合わせて出た iA Writer 5 から Dropbox 上のファイルへのアクセスが標準の「ファイル」経由になり、都度ダイアログから編集したいテキストファイルを選んで開かなければならなくなったからだ。iPhone ではテキストエディタ Textforce を使っているが、開発保守が止まっているようにみえるので違うのを探しておきたい。
で探したところ 1Writer を知った。開発はベトナム。2013年バージョン 1.0 リリースと既に実績のあるアプリのようだ。610円。3,680円する iA Writer よりかなりリーズナブル。
インストールしていると日本語版のインタフェースも用意されていてびっくり。ヌルヌルな操作感が気持ちいい。
などなど、自分のノートテキストファイル管理にとってパーフェクトだった。
最高では。 Dock 一番左の一番地にさっそくドラッグした。
[ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付に ]
テキストファイルと Google ドキュメント間で内容を同期したい件について引き続き検討。
Markdown ファイルをローカルで更新したら Google ドキュメントに自動できれいに反映されればベストだけれど、そういうのは無さそう。共有したいノートの作成・更新頻度を考えると手動にするか。
iA Writer の Web プレビューを全選択しコピーするとリッチテキストとしてクリップボードに入る。これを Google ドキュメントに貼り付けたところいい感じに書式付けされた。
Markdown ファイルの最初の見出しの次に Google ドキュメントの URL を HTML コメントで書いておけば、更新時にさっと開ける。 Google ドキュメントへの反映も思ったほどは億劫で無かった。
うん、これでいいかなと。
今日から運用開始する。
画像を データ URL 化して埋め込めば、その画像も Google ドキュメントに貼り付けられた。
[ ノート・日記はテキストファイルに ]
以前ノート間リンクのできるノートアプリを探してみた時に触った Obsidian をもう少し試してみた。
Obsidian は「ナレッジベース」アプリケーションで、一般的なノートアプリよりも情報間のネットワークを重視している。ローカルホスト上の特定フォルダ以下に置いた個別の Markdown ファイルを [[ファイルベース名]] 形式で内部リンクしていくのが基本。
ファイルの拡張子が md 固定で txt では駄目というのが個人的に不便(拡張子 txt にできないと Google ドライブ的に困る)なのだけれど、過去のノートテキストファイルの拡張子を変更してお試ししてみた。
ファイルベース名を指定して内部リンクを文中に書いていくのだが、ファイル名の先頭を日付にする流儀との相性が良くないな。[[ファイルベース名|表示テキスト]] 形式でプレビュー時のテキストを指定できるけど、編集モードだと文章として読みにくい。各ファイルで YAML front matter 形式で別名を宣言しておけばその別名で内部リンクできる機能があるので、丁寧に管理すれば読みやすくはできる。
ただ Obsidian 方言で書きすぎると「ローカルホスト上の Markdown ファイルなので特定アプリケーションに依存しない」良さがスポイルされてしまう。Markdown のショートカット参照リンク形式で内部リンクを張れるようになると良いのになと感じた。
1ファイル1トピックにしてきちんと内部リンクを張っていかないと価値あるグラフにならない。1日1ファイル + 個別トピックファイルというスタイルだと役に立たないかな。
検索は使いやすい。TaskPaper ほど優れてた UI ではないけれど、フォールディングやアウトライン表示もできたりする。デフォルトのスタイルは個人的に見出しが大きいなと感じるので、常用するなら CSS をいじる必要がありそう。
「時間とともに記録・整理しておきたいことが変遷していく」「ナレッジベースを作ること自体が主目的ではない」パーソナルナレッジベースの世界では、静的な情報を丁寧にネットワーク化していく百科事典型よりも日誌/日記型の方が良いと思ってる。内部リンクは編集・維持コストが高いので、パーソナルナレッジベースでは頑張らないのが幸せだ。
Obsidian は百科事典型のナレッジベースが欲しい人にはあいそう。一方自分のような日誌/日記型派にはやはり検索主体の howm 系の方がいいなとあらためて感じた。
[ Mac アプリケーション ] [ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付に ]
iA Writer の Web プレビューを Google ドキュメントに貼り付けて共有する方法で一緒に貼り付けられる画像はインターネット公開されているものだけなのがちょっと不便だった。iA Writer の Web プレビューのクリップボードコピーには画像データが直接含まれないため。
でいろいろ試したところ iA Writer 側で データ URL として画像を貼り付ければ、コピー & ペーストで Google ドキュメントに貼り付けられることが分かった。
画像データを base64 コマンドなどで base64 で符号化し、 Markdown ファイル上で

とすれば OK(image/png はメディアタイプに合わせる)。 iA Writer で Web プレビューで表示される。
とても長い URL なので文章中に直接含めておくのは不便。実際には img.png.txt など別のファイルに書いておいて
iA Writer の content block 機能を使って
/img.png.txt
のような形で include して実用するのが良さそうだ。ロケーションの中にファイルを置くことで検索にひっかかって不便な場合は、別のフォルダに置いて
../img/img.png.txt
のように相対指定かな。
[ ノート・日記はテキストファイルに ]
Markdown ファイルを iA Writer で Web プレビューしたものを Google ドキュメントに貼り付けて共有する(記事1)時、画像データをデータ URL 化して Markdown ファイルに記述すれば一緒に貼り付けられることが分かった(記事2)。
でもやっぱり管理が面倒くさい。
そこまでするなら「別のアプリで self-contained HTML に変換」→「Web ブラウザで表示」→「コピー & ペーストで Google ドキュメントに貼り付け」を実行する方がいいのでは。いったん HTML に書き出すのが嫌だなと今まで思っていたけれど。
と思って調べたら、インストールしてある Marked 2 が self-contained HTML に変換できたし、Google Chrome で表示して全選択からのコピー & ペーストで画像付きで Google ドキュメントに貼り付けられた。
こちらの方法にしよう。
昨日から使い始めた Zettelkasten メソッドのための機能を備えた Markdown エディタの2日目。昨日の時点で使い続けるかちょっと迷ったんだけれど、もうちょっと使い方を探ってみようと今日も使ってみている。内部リンク(ノート間リンク)の活用方法がちょっと分かってきて楽しい。
エディタ上で内部リンクを「command + クリック」「control + クリック」すると「リンク先のファイルを開く」と同時にその「リンク文字列での検索」が実行される。ファイルを開くと同時にいい感じに関連するファイルのリスト(実質バックリンクリスト)が表示されて便利。内部リンクを充実させたい気持ちが高まってきた。
アプリケーションに依存する Markdown ファイルを作らないという Zettlr の原則により Markdown ファイル中のどこに ID を書いてもいい仕様になっている。
自分としてはプレビュー時に文中に出ないように、昨日ひとまず ID を HTML コメントの形式で Markdown ファイルに埋め込んでみていた。 Zettlr やメインで使っている iA Writer、プレビューに使っている Marked 2 が YAML front matter に対応しているのでそこの方がわかりやすいかな。 front matter に ID を書くことにした。
日時については基本「2021-01-20-095836」という書式を使っているので Zettlr の ID のパターンも初日に「%Y-%M-%D-%h%m%s」にカスタマイズしたのだけれど「%Y%M%D%h%m%s」に戻した。過去のノートファイルに現在日時の ID を付与するというズレが心理的に気持ち悪かったので。
Also, our own experiences show that when one doesn't use easy-to-recognise IDs, one is less prone to assume stuff, making them better suited to cross-link files. Just try it yourself! -- https://docs.zettlr.com/en/academic/zkn-method/
というの納得。
内部リンクは Zettlr をナレッジベースとして使う上で便利だが、単独の Markdown ファイルをエクスポートして共有する際には不要だ。
Markdown ファイルを各種フォーマットに変換する Marked 2 に自作のカスタムプリプロセッサを通す機能があるので、 Zettlr で管理している Markdown ファイルを共有する際は Marked 2 を呼び出して
- [[...]]
を含む行を消してしまうように設定した。ノート関係の宣言のための内部リンクは上記のように独立した行に書いておこう。
これで個人的なナレッジベースとしてノート間リンクの充実させるという要求と、一部はエクスポートして共有したいという要求を満たせそうだ。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。 それとは別に nNote にもちょっとしたノートがあります。
※内容は個人的見解であり所属組織とは関係ありません。