Qiita:Team 活用のためにまだ試したことのなかった Mac アプリケーション Kobito をちょっとだけ使ってみました。
Qiita(Qiita:Team) 関連の機能としては投稿だけだと思っていたのですが、ローカルの変更を Qiita 側に再度反映させたり Qiita 側からダウンロードできて、いい意味で予想に反しておっと思いました。 Medium は Ulysses や iA Writer と双方向同期できるなら積極的に使うのになというのがあるのですが、 Kobito + Qiita ではそれが実現できていていいですね。
ただ Qiita:Team クライアントとして使うには、自分が投稿した記事しか同期できないという点で使い物にならないのが残念。自分自身が投稿した記事の管理にしても、ローカルホストのファイルシステム上の Markdown ファイルとして扱えるわけでもないので、自分としてはあまりメリットがないと感じました。
Kobito のログイン画面のユーザ名入力欄をみて「あっ」と思ったのですが、 Qiita:Team 専用アカウントとそうでない Qiita アカウントで同一ユーザ名を使えないのですね。2013年4月9日にリリースされた Qiita:Team は Qiita の上に建て増したあと付け感がやはり強いです。
Naney はパブリックな方で使えるようにしておきたいので、 Qiita:Team 側のユーザ名を変更しました。
[ Mac アプリケーション ]
去年の11月に自宅用に購入した NAS の Synology DiskStation DS216j に積んでいた WD Red NASハードディスクドライブ WD30EFRX (3TB) が故障したので急遽交換しました。昨晩に「劣化モード」に突入というアラートがあがったのでその場で新しい HDD を注文、速やかに本日交換しました。
7月10日にI/O エラー発生のアラートメール、1週間後の7月17日にファイルシステムエラーのアラートメールが届きました。このあたりからそろそろ意見だなと感じ始めました。
昨晩風呂に入った途端に Synology DiskStation DS216j がビープ音を鳴らし続け始めたので飛び出してきました。いったんコントロールパネルの[ハードウェアと電源]から[ビープ音をオフ]を押してビープ音を停止。ディスク 2 クラッシュでした。
状況を確認後いったんシャットダウン。
HDD モデルの問題なのか個体の問題なのか、それとも設置環境が悪かったのか、現状判別できないので、取り急ぎ最初に買った HDDを注文。
DS216j を起動した際に新しく書き込みしていかないように、まず MacBook Pro の Time Machine と Cloud Station を停止。
それから Debian GNU/Linux ノート PC の pdumpfs バックアップに以前使っていた8年前購入のポータブル HDD があったので DS216j を起動し背面の USB ポートに接続。とり急ぎバックアップ設定などはせずに File Station を使って DS216j 上のファイルをコピーしました。
とりあえずファイルロストの心配がこれでなくなったので一安心。
夜に HDD が届いたので DS216j を開けて交換。溜まっていたホコリをいったん綺麗にするのにちょっと時間をかけましたが、交換自体はささっと完了です。
交換したら DS216j を起動して修復を実行。19:30 過ぎに始めて夜中の 27:00 前に整合性チェックが完了しました。7時間30分弱で完了したようです。
これで一段落。
今回の故障の原因は何でしょうね。夏の暑さか、稼働中の衝撃があったのか、HDD の個体の問題だったのか。どちらにせよ先送りしていたバックアップ体制も構築しなければと思う1日でした。それにしても家に居ながらにして翌日には HDD を調達して修復を実行できるとは良い時代になりました。
MacBook Pro のリプレースにあたり Google ドライブのローカルへの同期を「ドライブ ファイル ストリーム」にしてみたんだけれど、自分の使い方ではデメリットが多いので即日「バックアップと同期」に戻した。
ドライブ ファイル ストリームなら実体はクラウドストレージ側にあるのでファイル数が多くてもへっちゃらではないか。そう思ったわけです。
機能比較で「Microsoft Office や Photoshop などのネイティブ アプリを使用する」とあったので、 Google Chrome 拡張機能の Application Launcher for Drive (by Google) が使えると思ったら使えなかった。ファイルシステム上で開けるという意味だったようだ。この拡張機能がないと「Chrome 上で Google ドライブ検索してからの、ネイティブアプリで閲覧編集」という使い方ができないので劇的に不便になる。
それから Finder (Path Finder でも)ブラウズできないフォルダがあってこちらは致命的な問題。ターミナルで cd していけるのだけれど Finder では駄目。これは駄目。
結局ドライブ ファイル ストリームはやめてバックアップと同期に戻すことにした。 archive フォルダをマイドライブ直下に作ってここは同期しないことにし、いったん全部そこに移動した。
選択同期は面倒なので今まで避けてきたけれどしかたあるまい。今後は作業中のフォルダだけ同期することにする。
Web ページやローカルファイル、ノートアプリ上のノートなどをリンクさせて相互に簡単に開けるようにする Mac アプリケーション Hook というのが現在パブリックβ版として配布されているので入れてみた。
動かしてようやくどう機能するかがわかってきた。リンクしたいものに URL スキームが hook の独自 URL を発行し(すでに URL がある Web ページの場合は発行されない)、双方向の第三者リンクを作成・管理し、トラバース(リンクを辿ってオープン)できるアプリケーションなんだ。W3C の XLink が頭に思い浮かんだ。
ローカルファイルが file URL スキームの URL だと移動したらリンクが切れるんじゃないかと思ったんだけれど、ローカルファイルにも hook://file/... というファイルシステム上のパスで表されない URL が発行されるので大丈夫だった。面白い。
対応しているアプリケーション上のリソースに対するリンクを発行すれば、そのアプリケーションで開いてくれる。 iThoughtsX が入っているのが嬉しい。 Ulysses も入っていてやったーとなったけれど、実まだ不完全ぽい。残念。
アプリケーションとしては面白いんだけれど、使い勝手的にはまだまだな感じかな。
[ Mac アプリケーション ]
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 みたいにローカルファイルシステムとの同期を前提とした設計で出発していないのか特殊な仕様が多いので、時々ハマるんだよね。
[ ノート・日記はテキストファイルに ]
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 アプリケーション ]
他人に見られる心配なしに書きたいノートテキストファイルを Google ドライブでバックアップしておくのに Cryptomator を使うことにした。
Cryptomator アプリケーションと macOS でファイルシステムとしてマウントするための macFUSE をインストール。
Google の「バックアップと同期」で同期しているフォルダ内に Cryptomator アプリケーションで vault を作成する。 vault を解錠するとファイルシステムとしてマウントされるので、そこでファイルを読み書きする。 vault フォルダ側には暗号化されたファイルが保存され「バックアップと同期」でバックアップされる。vault 側は直接いじらないようにする。
という理由からマウントしたフォルダ上で直接ファイルを読み書きせず、別の場所にあるノートフォルダを Unison でバックアップを有効にしつつリアルタイム同期することにした。
root = /Volumes/マウントポイント名 root = /path/to/ノードフォルダ times = true rsrc = false repeat = watch silent = true backup = Name * backuplocation = central maxbackups = 60 backupdir = /path/to/バックアップフォルダ
Cryptomator のファイルシステムに対して Unison が属性のコピーをしようとして失敗するので rsrc = false 指定が必要だ。
[ ノート・日記はテキストファイルに ]
以前から気になっていた Logseq を MacBook Pro にインストールして触ってみた。Logseq は WorkFlowy や Roam (Roam Research) などからインスパイアされて開発されているアウトライナーで、類似のインタフェースや機能を備えている。
ローカルの Markdown/Org ファイルにデータが保存されるので、他のアプリケーションと併用したり乗り換えたりするのが容易だ。ローカルで閉じて使えるのでネットサービス上に置きたくない情報を扱うのにも向いている。
Logseq の名前の由来が
What does "Logseq" mean? You can read it as "Log sequence" or "Logical sequence" (thank you Ed). — logseq.github.io
とあるように、ジャーナルに思い浮かんだことをキャプチャし書き出しながらナレッジやプロジェクトなどのためのページをつないでいくのが標準の構成となっている。このため Logseq graph (ページの集まりのことで、ファイルシステム上では指定したフォルダ以下に保存される)を新しく作成すると初期状態で Journals (journals フォルダ)が作られる。
自分は Obsidian でデイリーノート管理をしている。 Logseq を使うとジャーナル管理が2箇所になってしまうのがちょっと悩ましい。ジャーナル管理をオフにできるけれどそうすると Logseq らしさが無くなってしまいそうではある。
All pages に Contents・Favorites・card というページが表示されるのだがこれが何なのかまだ分かっていない。 refresh や re-index 操作があるのだけれどそれぞれいつ実行すべきかわからない。 どちらをやっても変更が反映されない場合があって、その時は All Graphs から graph を開き直すときれいになったりする。
Google ドライブアプリで同期している「Google ドライブ」フォルダ以下に graph を作ると、ファイル管理がおかしい。 graph フォルダの中にさらに Users/naney/Google ドライブ/... のようなフォルダ階層が作られてしまう。
いろいろ試したところ graph のフォルダまでのパスに濁点が含まれるフォルダ名があると駄目のようだ。Unicode 正規化まわりの問題に引っかかったようだ。
Google ドライブ同期フォルダ以下にある Obsidian vault フォルダ Logseq graph として開いてみる実験をしていて上記問題にぶつかり今日は終了。
アウトライナーは思考にするのにとても便利だが、作成したアウトラインは時間が経つと扱いづらくなる。自分としては Obsidian をメインに使う中で補助的に Logseq が使えればいいなと。明日もうちょっと触って構成を検討しよう。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。