Google ドライブにあるノートテキストファイルを参照したくなり、そこに必ず書かれていると分かっている単語で検索してみたけれど検索結果に出てこず「あれっ?」となった。検索結果に出るテキストファイルと出てこないテキストファイルがある。
違いを調べたところ Web 版 Google ドライブでテキストファイルの詳細を右側に表示した際に「縮小されたサムネイル」が表示されるものは全文検索対象になっていて、表示されないものは全文検索対象になっていないようだ。
でテキストファイルで「縮小されたサムネイル」が表示されるかどうかの違いだけれど、どうやら作成時(ローカルホスト上でファイルを作成して「バックアップと同期」で Google ドライブに最初にアップロードされる時を含む)に、拡張子が txt か md (Markdown ファイル)かで決まっているような挙動だった。最初に txt で作った後に md に変更しても全文検索対象だし、逆に最初に md で作ったファイルは後で txt に変更しても全文検索対象にならない。
Google ドライブで拡張子 md のテキストファイル(Markdown ファイル)が全文検索対象になっていることに9月に気が付いて、 Google ドライブに置く Markdown ファイルの拡張子を md に統一したのだけれど、その結果「もともと txt だったものを md にリネームしたもの」「もともと md だったものを過去に txt にして再度 md にリネーム」「md で新規作成してずっとそのままなもの」が混在していて、全文検索されるかどうかがもはやよくわからない状態になっているのが自分の現状っぽい。
単純に拡張子を変更するだけでは駄目なことがわかったので、いったん Google ドライブの同期対象フォルダから18,000以上あるノートテキストファイルを外に出して、拡張子を txt に統一し、あらためて Google ドライブの同期対象フォルダに戻して新規作成扱いにした。これで全部検索対象になった模様。
Google ドライブに置く予定がない Markdown ファイルもデフォルトで拡張子 txt で作るよう各種設定を変更し、Google ドライブに置いていない既存の Markdown なノートテキストファイルもだいたい txt に変更しておいた。あとで「Google ドライブに置いておこう → (Google ドライブに同期したあとに)拡張子 md だったから txt にしておこう」とした時に、人知れず検索対象からハズレているという事態を避けたいので。
Google ドライブは全文検索ができるのが便利だけれど、 Dropbox みたいにローカルファイルシステムとの同期を前提とした設計で出発していないのか特殊な仕様が多いので、時々ハマるんだよね。
[ ノート・日記はテキストファイルに ]
2018年に $44.95(2年)で更新した Flickr Pro、来月の更新は $49.99(1年)かーと思っていら、一昨日に $59.99(1年)に値上げするというメールが……。
2005年2月に登録し、その年の5月には Flickr Pro にアップグレード。ここ最近はほとんどアップロードしなくなったけれど「nDiki 上の過去記事の多くで Flickr 上の写真を表示している」のと「Twitter に投稿した Flickr への URL をデッドリンクにしたくない」のとで Flickr Pro を維持してきた。
nDiki 上の記事の写真の移行が進んでいないのでもう1回更新かなあと思っていたのだけれど、さすがにこの金額はもう無理。2月4日の更新前に移行作業をやりきることにした。
Flickr にアップロードする写真自体は全部ローカルにあるので失っても問題ない。
だけれど Flickr (Pro) をやめることで写真削除となった時に、Flickr 上でのフォト ID に対応する写真がどれだったが分からなくなるのは困る。ということで Flickr からまず写真をエクスポートすることにした。
Account settings ページの「Request my Flickr data」でまずダウンロードリクエストを行う。準備ができるとダウンロード用のリンクがそこに表示される。
自分の場合は「Account data」の ZIP ファイルが1つと「Photos and videos」に ZIP ファイルが7つできた。
前者はメタデータなどが入っており、後者には写真・動画ファイル(以下写真ファイル)そのものが入っている。全部で 3,052 写真ファイルだ。
写真ファイルのファイル名に微妙にタイトルが入っていたり入っていなかったりと統一されておらず扱いづらい。幸い必ずフォトID(7桁以上の数字列)が含まれていたので、リネームスクリプトを Perl で書いて「<フォト ID>.拡張子」に変換した。
www.naney.org に転送してそのまま nDiki に貼れるように Exif Orientation をみて画像を回転させる。
jhead -autorot *.jpg
今 nDiki では画像ファイルの画像サイズは長辺 1,200px ピクセル以下にするようにしている(記事)。長辺が指定サイズより大きい画像ファイルだけをまとめてリサイズできる Th-MakerX
を利用した。
出来上がったファイルを1つのディレクトリに入れて www.naney.org にアップロード(同期)。これで Flickr 上にあった写真(を調整したもの)を www.naney.org 上に置くことができた。
nDiki の過去記事で Flickr 上の写真を表示させているものをいくつか編集して www.naney.org 上の写真を表示するようにしてみたところうまくいっている感じ。
思ったより早く移行できちゃうかも。
[ サブスクリプションサービス ]
2020年9月30日以降 Google ドライブで複数のフォルダにアイテムを配置できなくなると知ったので、全てひとり親になるよう変更した。
2020 年 9 月 30 日以降は、複数のフォルダにアイテムを配置することができなくなり、アイテムの位置は 1 つだけになります。 -- Google ドライブのフォルダ構造と共有モデルを簡素化 | Google Cloud Blog
Google ドライブ上でショートカットが作れるのだけれど「バックアップと同期」した Mac 上では
と「別のフォルダに追加」したのと使い勝手が異なる。
フォルダを別のフォルダに追加する機能を便利に使っていたのでちょっと残念。
ノートアプリとして使っている iA Writer であるといいなと思っている機能の1つにノート間リンク(内部リンク)がある。テキストファイル管理タイプのノートアプリでノート間リンクのできるものがあるかなといくつか試してみた。
今日のチェックではヒットなし。
PopClip 拡張を自作して、キーワードからターゲットとなるテキストファイルを iA Writer で開くようにするのがいいように思えてきたぞ。
[ Mac アプリケーション ]
紙に万年筆で書き出すのが考えを巡らせるのに良いなと思いつつ、何度も整理し直しながら進めたい時はやはりデジタルで。テキストファイルアウトライナーとして TaskPaper を久しぶりに起動。
iA Writer for Mac って前から拡張子 taskpaper のファイルをファイルリストに表示したりエディタで開いたりできたっけかな。今日やってみたら対応していたので、拡張子 taskpaper のまま Markdown 形式で書いているノートテキストファイルと同じにフォルダに入れてもいいか。
以前ノート間リンクのできるノートアプリを探してみた時に触った Obsidian をもう少し試してみた。
Obsidian はナレッジベースアプリケーションで、一般的なノートアプリよりも情報間のネットワークを重視している。ローカルホスト上の特定フォルダ以下に置いた個別の Markdown ファイルを [[ファイルベース名]] 形式で内部リンクしていくのが基本。
ファイルの拡張子が md 固定で txt では駄目というのが個人的に不便(拡張子 txt にできないと Google ドライブ的に困る)なのだけれど、過去のノートテキストファイルの拡張子を変更してお試ししてみた。
ファイルベース名を指定して内部リンクを文中に書いていくのだが、ファイル名の先頭を日付にする流儀との相性が良くないな。[[ファイルベース名|表示テキスト]] 形式でプレビュー時のテキストを指定できるけど、編集モードだと文章として読みにくい。各ファイルで YAML front matter 形式で別名を宣言しておけばその別名で内部リンクできる機能があるので、丁寧に管理すれば読みやすくはできる。
ただ Obsidian 方言で書きすぎると「ローカルホスト上の Markdown ファイルなので特定アプリケーションに依存しない」良さがスポイルされてしまう。Markdown のショートカット参照リンク形式で内部リンクを張れるようになると良いのになと感じた。
1ファイル1トピックにしてきちんと内部リンクを張っていかないと価値あるグラフにならない。1日1ファイル + 個別トピックファイルというスタイルだと役に立たないかな。
検索は使いやすい。TaskPaper ほど優れてた UI ではないけれど、フォールディングやアウトライン表示もできたりする。デフォルトのスタイルは個人的に見出しが大きいなと感じるので、常用するなら CSS をいじる必要がありそう。
「時間とともに記録・整理しておきたいことが変遷していく」「ナレッジベースを作ること自体が主目的ではない」パーソナルナレッジベースの世界では、静的な情報を丁寧にネットワーク化していく百科事典型よりも日誌/日記型の方が良いと思ってる。内部リンクは編集・維持コストが高いので、パーソナルナレッジベースでは頑張らないのが幸せだ。
Obsidian は百科事典型のナレッジベースが欲しい人にはあいそう。一方自分のような日誌/日記型派にはやはり検索主体の howm 系の方がいいなとあらためて感じた。
[ Mac アプリケーション ] [ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付に ]
Zettelkasten メソッドのための機能を備えた Markdown エディタに Zettlr がある。ローカルディレクトリ上に通常の Markdown ファイルとしてデータを保存するタイプで、ロックインの心配が無く他のツールと併用できる好みのアプリだ。インストールして1日使ってみた。
Homebrew では以下で。
$ brew install --cask Zettlr
今日時点でインストールされるのが 1.8.3 でちょっと古かったので
からバイナリビルドされた 1.8.6 をダウンロードしてインストールした。
ヘッダを大きめに表示したりリンクの URL を隠したりと一部プリレンダリングされるタイプ。日本語も問題無さそう。
ファイル末のあたりで文字入力するとエディタがガクガク揺れるは今後改善されると嬉しい。
見出し単位で折り畳む機能やサイドバーで目次を表示する機能があり、長めの文章を書くための支援が揃っている。
ファイルツリー上にディレクトリとファイルの両方を表示する Combined モード以外に、ファイルツリー(ディレクトリツリー)とファイルリストの両方を表示する Expanded モード、ファイルツリーとファイルリストのどちらかを表示する Thin モードがある。
Expanded モードを選ぶと iA Writer や Ulysses などでもお馴染みのスタイルになりノートアプリとして使いやすくなる。
ファイルシステム上のディレクトリをルートディレクトリとしたワークスペースを複数同時に開いておける。用途別にディレクトリを分けている場合に便利だ。
全文検索はワークスペース単位。内部リンクもワークスペース単位で機能する。 自分は複数のワークスペースを横断的に全文検索したいので、本格的に使うなら1つのディレクトリの下にまとめる必要があるな。
ファイルの拡張子は md ではなく txt でも OK なので、ファイルを同期した Google ドライブ上で全文検索させられるのが嬉しい(Markdown ファイルの拡張子を md にすると Google ドライブで不便)。 md 固定の Obsidian より柔軟だ。
Makrdown ファイルから Markdown ファイルへファイルベース名を指定して 「[[ファイルベース名]]」の形で内部リンクできる(パス名は不要)。
また Markdown ファイル内にユニークな ID を書いておき、その ID を指定して「[[ID]]」としてリンクもできる。後者を使えばファイル名変更が気軽にできる。 ID の形式やリンクの開始文字列 [[ ・終了文字列 ]] もカスタマイズできて柔軟なのも良い。
iA Writer では
ia-writer://open?path=/Locations/path/to/file.txt
のような URL を発行して擬似的にリンクするさせるしかないので比べると圧倒的に便利。
今メインで使っている Mac アプリケーションの iA Writer に比べると Electron ベースの Zettlr は美しさで負けるのは仕方ないところかな。
Zettlr をテキストファイルノートアプリとして内部リンクを活用しながらパーソナルナレッジベースを作っていくのありだな。
[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]
拡張子 md の Markdown ファイルを「バックアップと同期」アプリで新規に同期したり、 Web 版の Google ドライブでアップロードしたりすると MIME タイプが text/markdown となり全文検索対象にならない。不便。
StackEdit は Google ドライブに送る時の MIME タイプを設定で text/plain を選べるようにすることで問題を回避しているようだ。
クラウドストレージ上のファイルを管理するためのコマンドラインプログラム rclone でアップロードするとどうだろうと思ってやってみたところ、ちょっと設定をいじれば拡張子 md の Markdown ファイルを text/plain で Google ドライブにアップロードできることがわかった。
rclone では Google Drive API で新しいファイルを作成する際に、rclone 側で MIME タイプを判定している。内部的には Go の mime パッケージを使っている。
このパッケージは UNIX 系の環境では mime.type ファイルがあれば参照するようになっていたので macOS Catalina にあった /etc/apache2/mime.type ファイルの text/plain 行に md を追加して試したところ、めでたく text/plain として Google ドライブにアップロードできた。全文検索対象になることも確認。
ちなみに「バックアップと同期」アプリは /etc/apache2/mime.type 変更の影響を受けなかった。
rclone での方法が分かったわけだけれど、実際のところ Markdown ファイルの Google ドライブとの同期や読み書きを rclone だけに限定するわけにもいかないな。引き続き拡張子 txt で管理するのが現実的のようだ。
去年の夏・12月と試したあと距離を置いていたナレッジベースアプリケーション Obsidian が気になってまた使ってみることにした。
Roam Research も気になるけれどやはりデータがテキストファイルじゃないというのがね。
Obsidian を躊躇していた点については以下のように考え運用してみることにする。
過去の全部のノートテキストファイルを対象とするのではなく、特定ドメインの知識整理用としてゆるく切り離して使う。
Obsidian の拡張子が md 固定でそのまま Google ドライブに同期しても全文検索できない問題については、Google ドライブで全文検索したい拡張子 txt の日記/日誌系 Markdown ファイルを Obsidian vault には入れず、今まで通り別で管理することで回避することにした。
[[ファイルベース名]] や [[ファイルベース名|表示テキスト]] という内部リンク方言についても、 Obsidian の vault 内でノートでは許容しよう(許容しないと Obsidian を使う意味が無いので)。エクスポートする時は[[・]]を消すプリプロセッサを用意して Marked 2 で使うようにする。
[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]
昨日考えた方針通り Google ドライブで全文検索する必要のない Markdown ファイルの拡張子を txt から md に変更し、Obsidian vault を作成した。そこそこファイル数があるが Zettlr に比べて検索が圧倒的に速くてサクサクだ。いけそう。
1つのファイルに複数の情報が書かれているデイリーノートファイルがあると、同日に扱ったという点以外で関連のないものが関連があるかのようなグラフになってイケてない。
フィルタでデイリーノートファイルを -file:... を使って除外したらいい感じになった。なるほど。
試してみたいけれど $96/年に見合うほど使わなさそう。HTTPS なカスタムドメインを設定するのが現時点でハードルが高いということもあり様子見。様子見していて 50% early bird 価格が終わっちゃったら、さらに遠のいちゃうかもしれない。
[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
※内容は個人的見解であり所属組織とは関係ありません。