nDiki : 拡張子

Flickr Pro をやめることにする

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>.拡張子」にする

写真ファイルのファイル名に微妙にタイトルが入っていたり入っていなかったりと統一されておらず扱いづらい。幸い必ずフォトID(7桁以上の数字列)が含まれていたので、リネームスクリプトを Perl で書いて「<フォト ID>.拡張子」に変換した。

画像を回転する

www.naney.org に転送してそのまま nDiki に貼れるように Exif Orientation をみて画像を回転させる。

 jhead -autorot *.jpg

画像をリサイズする

今 nDiki では画像ファイルの画像サイズは長辺 1,200px ピクセル以下にするようにしている(記事)。長辺が指定サイズより大きい画像ファイルだけをまとめてリサイズできる Th-MakerX

• Th-MakerX

を利用した。

www.naney.org にアップロード

出来上がったファイルを1つのディレクトリに入れて www.naney.org にアップロード(同期)。これで Flickr 上にあった写真(を調整したもの)を www.naney.org 上に置くことができた。

nDiki の過去記事で Flickr 上の写真を表示させているものをいくつか編集して www.naney.org 上の写真を表示するようにしてみたところうまくいっている感じ。

思ったより早く移行できちゃうかも。

[ サブスクリプションサービス ]

Google ドライブで複数のフォルダにアイテムを配置できなくなる

2020年9月30日以降 Google ドライブで複数のフォルダにアイテムを配置できなくなると知ったので、全てひとり親になるよう変更した。

2020 年 9 月 30 日以降は、複数のフォルダにアイテムを配置することができなくなり、アイテムの位置は 1 つだけになります。 -- Google ドライブのフォルダ構造と共有モデルを簡素化 | Google Cloud Blog

Google ドライブ上でショートカットが作れるのだけれど「バックアップと同期」した Mac 上では

• ファイルのショートカット → Mac 上でもファイルになるのでそのまま編集できる。
• フォルダのショートカット → Mac 上では 拡張子 gshortcut のファイルになる。フォルダの中身まで Mac 上では辿れない。

と「別のフォルダに追加」したのと使い勝手が異なる。

フォルダを別のフォルダに追加する機能を便利に使っていたのでちょっと残念。

今日のさえずり: 今朝みたらタケノコ伐採されてたの……

• 06:15 うなじ。 #photography RICOH GR III #GR #GRIII #GR3 https://t.co/DjfQm44anZ
• 13:47 Google Chrome の Picture-in-Picture Extension を使って Google Meet の動画を最前面に固定してみている。なかなか便利。 #WFH #GoogleMeet https://bit.ly/2XHoeVf
• 19:00 今朝みたらタケノコ伐採されてたの……。
• 20:54 2020年9月30日以降 Google ドライブで複数のフォルダにアイテムを配置できなくなると知ったので、全てひとり親になるよう変更した。別のフォルダに追加する機能便利なのでちょっと残念。
• 21:02 Google ドライブ上でフォルダのショートカットを作ると「バックアップと同期」した Mac 上では拡張子 gshortcut のファイルになっちゃうんだよね。
• 21:04 Google ドライブ上でファイルのショートカットを作った場合は「バックアップと同時」した Mac 上でもファイルになるので「別のフォルダに追加」したのと使い勝手はあまり変わらない。
• 21:15 御神木 #photography RICOH GR III #GR #GRIII #GR3 https://t.co/PY5wuFfa1U

ノート間リンクのできるノートアプリを探す

ノートアプリとして使っている iA Writer であるといいなと思っている機能の1つにノート間リンク(内部リンク)がある。テキストファイル管理タイプのノートアプリでノート間リンクのできるものがあるかなといくつか試してみた。

• FSNotes
  • https://fsnot.es/
  • [[title]]でリンクができていい線いっている。1つのフォルダ以下をストレージにするタイプなので、複数のフォルダをロケーションしている iA Writer と併用できず。
• Obsidian
  • https://obsidian.md/
  • FSNotes 同様[[...]]の形式でリンクできる。ファイルの拡張子が md 固定で txt が駄目だった(拡張子 txt にできないと Google ドライブ的に困る)。
• Markdown Notes (Visual Studio Code 拡張)
  • https://marketplace.visualstudio.com/...
  • これもちょっと違う感じ。

今日のチェックではヒットなし。

PopClip 拡張を自作して、キーワードからターゲットとなるテキストファイルを iA Writer で開くようにするのがいいように思えてきたぞ。

[ Mac アプリケーション ]

TaskPaper 形式ファイルを拡張子 taskpaper のままで使う

紙に万年筆で書き出すのが考えを巡らせるのに良いなと思いつつ、何度も整理し直しながら進めたい時はやはりデジタルで。テキストファイルアウトライナーとして TaskPaper を久しぶりに起動。

iA Writer for Mac って前から拡張子 taskpaper のファイルをファイルリストに表示したりエディタで開いたりできたっけかな。今日やってみたら対応していたので、拡張子 taskpaper のまま Markdown 形式で書いているノートテキストファイルと同じにフォルダに入れてもいいか。

今日のさえずり: 「ちくわ笛」にできそうかという観点でちくわ選びしている

• 08:09 たけしたモーニング #photography RICOH GR III #GR #GRIII #GR3 https://t.co/k7q5CIFOS9
• 13:30 鳥居の前髪 #photography RICOH GR III #GR #GRIII #GR3 https://t.co/F9TZhrvPqP
• 14:55 今日もいい天気ですねー。 #photography #Pixel4 https://t.co/MW162DeoxZ
• 20:25 久しぶりにテキストファイルアウトライナーとして TaskPaper 使ってる。
• 20:27 iA Writer って前から拡張子 taskpaper のファイルをファイルリストに表示したりエディタで開いたりできたっけかな。やってみたら大丈夫だったので同じフォルダで管理しても良さそう。
• 20:38 「鳥居の前髪」は先日初めて訪問した花園神社の。
• 21:39 「ちくわ笛」にできそうかという観点でちくわ選びしている。

百科事典型ナレッジベースに向いているナレッジベース Obsidian

以前ノート間リンクのできるノートアプリを探してみた時に触った Obsidian をもう少し試してみた。

• https://obsidian.md/

Obsidian はナレッジベースアプリケーションで、一般的なノートアプリよりも情報間のネットワークを重視している。ローカルホスト上の特定フォルダ以下に置いた個別の Markdown ファイルを [[ファイルベース名]] 形式で内部リンクしていくのが基本。

ファイルの拡張子が md 固定で txt では駄目というのが個人的に不便(拡張子 txt にできないと Google ドライブ的に困る)なのだけれど、過去のノートテキストファイルの拡張子を変更してお試ししてみた。

内部リンク

ファイルベース名を指定して内部リンクを文中に書いていくのだが、ファイル名の先頭を日付にする流儀との相性が良くないな。[[ファイルベース名|表示テキスト]] 形式でプレビュー時のテキストを指定できるけど、編集モードだと文章として読みにくい。各ファイルで YAML front matter 形式で別名を宣言しておけばその別名で内部リンクできる機能があるので、丁寧に管理すれば読みやすくはできる。

ただ Obsidian 方言で書きすぎると「ローカルホスト上の Markdown ファイルなので特定アプリケーションに依存しない」良さがスポイルされてしまう。Markdown のショートカット参照リンク形式で内部リンクを張れるようになると良いのになと感じた。

グラフ表示

1ファイル1トピックにしてきちんと内部リンクを張っていかないと価値あるグラフにならない。1日1ファイル + 個別トピックファイルというスタイルだと役に立たないかな。

その他

検索は使いやすい。TaskPaper ほど優れてた UI ではないけれど、フォールディングやアウトライン表示もできたりする。デフォルトのスタイルは個人的に見出しが大きいなと感じるので、常用するなら CSS をいじる必要がありそう。

パーソナルナレッジベースとして

「時間とともに記録・整理しておきたいことが変遷していく」「ナレッジベースを作ること自体が主目的ではない」パーソナルナレッジベースの世界では、静的な情報を丁寧にネットワーク化していく百科事典型よりも日誌/日記型の方が良いと思ってる。内部リンクは編集・維持コストが高いので、パーソナルナレッジベースでは頑張らないのが幸せだ。

Obsidian は百科事典型のナレッジベースが欲しい人にはあいそう。一方自分のような日誌/日記型派にはやはり検索主体の howm 系の方がいいなとあらためて感じた。

[ Mac アプリケーション ] [ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付にする ]

Zettlr はテキストファイルノートアプリに適した Markdown エディタ

Zettelkasten メソッドのための機能を備えた Markdown エディタに Zettlr がある。ローカルディレクトリ上に通常の Markdown ファイルとしてデータを保存するタイプで、ロックインの心配が無く他のツールと併用できる好みのアプリだ。インストールして1日使ってみた。

• https://www.zettlr.com/
• https://docs.zettlr.com/ja/

インストール (macOS )

Homebrew では以下で。

 $ brew install --cask Zettlr

今日時点でインストールされるのが 1.8.3 でちょっと古かったので

• https://github.com/Zettlr/Zettlr/releases

からバイナリビルドされた 1.8.6 をダウンロードしてインストールした。

Markdown エディタとして

ヘッダを大きめに表示したりリンクの URL を隠したりと一部プリレンダリングされるタイプ。日本語も問題無さそう。

ファイル末のあたりで文字入力するとエディタがガクガク揺れるは今後改善されると嬉しい。

見出し単位で折り畳む機能やサイドバーで目次を表示する機能があり、長めの文章を書くための支援が揃っている。

ファイル管理

ファイルツリー上にディレクトリとファイルの両方を表示する Combined モード以外に、ファイルツリー(ディレクトリツリー)とファイルリストの両方を表示する Expanded モード、ファイルツリーとファイルリストのどちらかを表示する Thin モードがある。

Expanded モードを選ぶと iA Writer や Ulysses などでもお馴染みのスタイルになりノートアプリとして使いやすくなる。

ファイルシステム上のディレクトリをルートディレクトリとしたワークスペースを複数同時に開いておける。用途別にディレクトリを分けている場合に便利だ。

全文検索はワークスペース単位。内部リンクもワークスペース単位で機能する。 自分は複数のワークスペースを横断的に全文検索したいので、本格的に使うなら1つのディレクトリの下にまとめる必要があるな。

ファイルの拡張子は md ではなく txt でも OK なので、ファイルを同期した Google ドライブ上で全文検索させられるのが嬉しい(Markdown ファイルの拡張子を md にすると Google ドライブで不便)。 md 固定の Obsidian より柔軟だ。

Zettelkasten メソッドと内部リンク

Makrdown ファイルから Markdown ファイルへファイルベース名を指定して 「[[ファイルベース名]]」の形で内部リンクできる(パス名は不要)。

また Markdown ファイル内にユニークな ID を書いておき、その ID を指定して「[[ID]]」としてリンクもできる。後者を使えばファイル名変更が気軽にできる。 ID の形式やリンクの開始文字列 [[ ・終了文字列 ]] もカスタマイズできて柔軟なのも良い。

iA Writer では

 ia-writer://open?path=/Locations/path/to/file.txt

のような URL を発行して擬似的にリンクするさせるしかないので比べると圧倒的に便利。

1日使ってみて

今メインで使っている Mac アプリケーションの iA Writer に比べると Electron ベースの Zettlr は美しさで負けるのは仕方ないところかな。

Zettlr をテキストファイルノートアプリとして内部リンクを活用しながらパーソナルナレッジベースを作っていくのありだな。

[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]

Google ドライブで 拡張子 md の Markdown ファイルを全文検索できるように rclone でコピーする

拡張子 md の Markdown ファイルを「バックアップと同期」アプリで新規に同期したり、 Web 版の Google ドライブでアップロードしたりすると MIME タイプが text/markdown となり全文検索対象にならない。不便。

StackEdit は Google ドライブに送る時の MIME タイプを設定で text/plain を選べるようにすることで問題を回避しているようだ。

rclone で text/plain で Google ドライブにアップロードする

クラウドストレージ上のファイルを管理するためのコマンドラインプログラム rclone でアップロードするとどうだろうと思ってやってみたところ、ちょっと設定をいじれば拡張子 md の Markdown ファイルを text/plain で Google ドライブにアップロードできることがわかった。

• https://rclone.org/

rclone では Google Drive API で新しいファイルを作成する際に、rclone 側で MIME タイプを判定している。内部的には Go の mime パッケージを使っている。

• https://golang.org/pkg/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 で管理するのが現実的のようだ。

Obsidian やっぱり使ってみる

去年の夏・12月と試したあと距離を置いていたナレッジベースアプリケーション Obsidian が気になってまた使ってみることにした。

• https://obsidian.md/

Roam Research も気になるけれどやはりデータがテキストファイルじゃないというのがね。

Obsidian を躊躇していた点については以下のように考え運用してみることにする。

特定ドメインの知識整理用として使う

過去の全部のノートテキストファイルを対象とするのではなく、特定ドメインの知識整理用としてゆるく切り離して使う。

Obsidian の拡張子が md 固定でそのまま Google ドライブに同期しても全文検索できない問題については、Google ドライブで全文検索したい拡張子 txt の日記/日誌系 Markdown ファイルを Obsidian vault には入れず、今まで通り別で管理することで回避することにした。

[[ファイルベース名]] や [[ファイルベース名|表示テキスト]] という内部リンク方言についても、 Obsidian の vault 内でノートでは許容しよう(許容しないと Obsidian を使う意味が無いので)。エクスポートする時は[[・]]を消すプリプロセッサを用意して Marked 2 で使うようにする。

[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]

Obsidian 使い方分かってきて楽しい

昨日考えた方針通り Google ドライブで全文検索する必要のない Markdown ファイルの拡張子を txt から md に変更し、Obsidian vault を作成した。そこそこファイル数があるが Zettlr に比べて検索が圧倒的に速くてサクサクだ。いけそう。

グラフビュー

1つのファイルに複数の情報が書かれているデイリーノートファイルがあると、同日に扱ったという点以外で関連のないものが関連があるかのようなグラフになってイケてない。

フィルタでデイリーノートファイルを -file:... を使って除外したらいい感じになった。なるほど。

Obsidian Publish

試してみたいけれど $96/年に見合うほど使わなさそう。HTTPS なカスタムドメインを設定するのが現時点でハードルが高いということもあり様子見。様子見していて 50% early bird 価格が終わっちゃったら、さらに遠のいちゃうかもしれない。

[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]

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

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

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

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

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

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