nDiki : ファイル名

今日のさえずり: 松屋の白ドレッシング、袋でなくてボトルなら欲しいんだけれどなー

2018年04月29日

• 07:31 左手の小指の爪が割れてきたのでセロハンテープを貼ってみた。絆創膏だと手を洗った時にガーゼの部分が湿るし貼ってる面積も大きいしでタイピングしにくいので。
• 08:56 @KINAMANGHURAN ありがとうございます。トップコート1本持ってると便利そうですね!
• 11:44 破壊したはずでは… https://t.co/r3zqjovxku
• 12:00 丁度良い距離で達成感の高いコースだったのでお勧め。 / “歩く会: 神田川沿いを踏破” http://bit.ly/2oREinh
• 12:51 新緑が気持ちいい! (@ 小石川後楽園 in 文京区, 東京都) https://www.swarmapp.com/c/kpoJPPwQRSP
• 14:42 広いので駅前なのに空いてるし、競馬新聞読んでる方もいる。 (@ EXCELSIOR CAFFÉ 水道橋西口店 in 千代田区, 東京都) https://www.swarmapp.com/c/9rhTsG0xlaG
• 17:39 RAW ファイル用の jhead みたいなツールあるのかな。撮影日時に合わせてファイル名を変更できるやつ。
• 17:43 ExifTool かな。
• 20:23 松屋の白ドレッシング、袋でなくてボトルなら欲しいんだけれどなー。

このゴールデンウィークから RAW 画像形式で記録し処理し始めた

ゴールデンウィーク最終日。今回のゴールデンウィークで個人的にやろうと思っていたことの1つがデジカメで「RAW 画像」で記録して、PC で処理・管理できるようにすることでした。

「スマートフォン・PC に転送する時どうなるの?」「RAW ファイルをどのように管理しよう」「ストレージの容量を圧迫しそう」「ソフトウェアを用意し使い方を学ぶ必要がある」「RAW 現像に無限に時間が取られそう」などの懸念があってなかなか手を出してこなかったのですが、ゴールデンウィークというまとまった時間でやってみることにしました。

デジタルカメラの設定

デジタルカメラ側は α6300(ソニー)・DSC-RX0(ソニー)・PowerShot G9 X Mark II(キヤノン)でそれぞれ RAW + JPEG で保存するようにして終わり。

スマートフォンへの転送

外出先でソーシャルメディアに投稿する時にデジカメからスマートフォンへ Wi-Fi 転送しています。 RAW ファイルまで転送されたら時間がかかるのでは懸念していましたが、ソニー機・キヤノン機どちらも JPEG ファイルのみ転送するようになっていて問題なしでした。

PC への Wi-Fi 転送

ソニー機から自宅で Mac へ Wi-Fi 転送しています(キヤノンは未対応)。スマートフォンの時とは逆にこちらは RAW ファイルも転送して欲しい訳ですが、期待通り両方転送してくれてました。問題なし。

RAW ファイルのファイル名

JPEG ファイルは「画像ファイル名の先頭を日時にする」(例えば 2018-05-05-123456-ILCE-6300.jpg) (記事)に統一しています。 RAW ファイルは同時に記録した JPEG ファイルと同じファイル名 + RAW 画像形式の拡張子にしたいところ。

JPEG 画像ファイルのリネームには jhead を使っているので、 RAW ファイルでも同様のコマンドラインツールが無いかと探してみました。

調べると ExifTool が RAW 画像ファイル形式中の撮影データを扱えるということがわかりました。以下のようなスクリプトでリネームするようにして解決。

 #!/bin/sh
 chmod 644 $@
 exiftool '-FileModifyDate<CreateDate' $@
 exiftool -d %Y-%m-%d-%H%M%S%%-c-ILCE-6300.arw '-FileName<CreateDate' $@

RAW ファイルの管理

カメラの撮って出し JPEG 画像でいいかなと思う時はさくっと消すことにしました。調整したいなと思った場合は RAW ファイルから現像し

• オリジナル RAW ファイル
• オリジナル JPEG ファイル
• 編集後 RAW ファイル
• 現像書き出しした JPEG ファイル
• 現像書き出しした JPEG ファイル (記事/投稿用リサイズ版)

をとりあえず保存してみています。ここはもうちょっと整理しても良さそう。

現像ソフトウェア

いったんデジタルカメラメーカーが出しているもので。

• ソニー: Imaging Edge
• キヤノン: Digital Photo Professional 4

メーカー別にソフトウェアを使い分けるの面倒なのでどうしようという感じです。 Lightroom Classic CC にするのがいいのかな?

まだパラメータ調整で思ったような絵作りができないので、まずはそこを学びたいところです。

Lightroom CC mobile で編集した JPEG ファイルの整理手順

外出先でスマートフォンに写真(JPEG ファイル)を転送し Lightroom CC mobile で編集・書き出してソーシャルメディアに投稿したあと、手元にある現像された写真を管理する手順をちょっと考えてます。

家に帰って Lightroom Classic CC で同期したあと、 MacBook Pro で単純にファイルを移動したりしてたら現像設定が消えてあれあれとなったので、いったん以下の手順でやることにしました。

以下 Lightroom Classic CC での操作

1. Lightroom CC mobile で編集した写真をローカルに同期する(自動)。
2. Lightroom CC mobile で編集した写真に対して「メタデータをファイルに保存」を実行。 (現像設定を含むメタデータを JPEG ファイル内に書き込む)。
3. 写真ファイルをいったん「Lightroom からのみ除去」。 (クラウドの同期を外す)
4. 普段使っているオレオレルールリネームスクリプトで名前を変更。(ここはターミナルでの作業。)
5. 「フォルダーを同期」で Lightroom Classic CC カタログへ写真を読み込み。
6. ファイル名に Lr をつける。(デジカメから直接取り込んだ未現像のファイルと区別するためのオレオレルール)
7. 保存したいフォルダーに移動する。

前はメタデータを JPEG ファイルに保存していなかったため、 Lightroom CC の同期から外した時点で現像設定が消えちゃっていました。 Lightroom Classic CC の方はカタログ設定で「JPEG、TIFF、PNG、および PSD ファイル内のメタデータに現像設定を含める」をオンにしてあったため、 Lightroom 同期した時点でローカルに作られた JPEG ファイルに現像設定が書き込まれていると誤解してました。

もっとスマートな方法があれば知りたい。

Day One Premium をキャプチャツールとして使うのを控える

Day One 3 で作成/編集したエントリが Android 版では編集できなくなったのだが Android 版が追従する様子がみられない。今の状態だと iPhone 上の Day One をキャプチャツールと使うので支障がある。いったんキャプチャ先をできるだけテキストファイルベースに戻すことにする。

Android デバイスでは JotterPad で。日時形式のファイル名をつけるのが一手間なの変わらず。 Clipper Plus のダイナミック(日付・時刻などのテンプレート)を使って現在日時のファイル名を生成してクリップボードにコピーできるようにしておいた。

iPhone では iOS 版の Ulysses で。こちらでメモる頻度が低いので Gboard の「日時」変換で仮に入力しておいてあとで修正かな。

Mac は今まで通り Alfred の workflow から。ファイルを作る先別に workflow を使い分けていたのだけれど、キャプチャする時に頭に負荷をかけるのを減らした方がいいなということで inbox ディレクトリに保存する1つだけに絞った。

キャプチャの容易さと日時管理のしやすさの点で Day One は優れているんだけれどなあ。

[ ファイル名の先頭を日付に ]

Alfred 3 for Mac の表示量を増やす

Alfred を使っていて

• search text の文字数が少なくて長めのテキストを入力する時に全体が見えない
• result text の文字数が少なくて似たような長いファイル名が複数あると区別できない

と不便に感じるようになったのでサイズを変更してみた。

Alfred Preferences の Appearance で Alfred macOS Theme を複製し、

• Window Width: 559px を 1024px に
• Search Text Size: 34px から 24px に
• Result Text Size: 18px から 16px に

に変更。これで一度にだいぶ見渡せるようになった。参照したい表示の上に Alfred がかぶった時のために透明度を上げた方が良いかなと思っていたけれど blur がかかっていてどのみち読めなさそうだったのでここは変更せず。

• https://www.alfredapp.com/

Ulysses で TextBundle を使うのどうなのか調べてみた

Markdown 形式ファイルと、そこから参照されている画像ファイルを1つにまとめて管理する形式として TextBundle がある。ライティングアプリ Ulysses が対応しているのでちょっといじってみた。

• http://textbundle.org/

TextBundle は package format と compressed format がある。 package format は macOS のパッケージの形になっていて、 textbundle という拡張子をつけたディレクトリの中に info.json と text.* (Markdown なら text.md)、それからテキストファイルから参照しているファイルを asserts/ サブディレクトリに置くという仕様である。macOS の Finder からは1つのファイルのように表示される。

TextBundle を使うメリット

メリットは以下。

• テキストファイルと参照されている画像ファイルを一緒に管理できる(ばらけないで移動したりできる)。
• TextBundle に対応していないテキストエディタでも text.md を簡単に開いて編集できる。

TextBundle を使うデメリット

非対応アプリケーションから使う場合にデメリットを感じる。

• 非対応アプリからみると TextBundle 毎にディレクトリがあることになるので、ディレクトリだらけな感じになる。ドキュメント毎にディレクトリを開いて中のテキストファイルにアクセスする必要がある。
• Markdown ファイル名が text.md 固定なので、ファイル名だけでは区別できなくなる。

Ulysses for Mac の場合

Ulysses は TextBundle に対応しているので通常の Markdown ファイルと同様1つのシートとして自然に扱える。

普段 Ulysses for Mac では Dropbox の中のディレクトリを外部フォルダとして指定して使っているので以下、外部フォルダの時の話し。

Ulysses の外部フォルダ上の Markdown ファイルに貼った画像をエディタ上でプレビューできるのは現状 TextBundle だけ。エクスポート時も TextBundle 内の画像ファイルは書き出されれるけれど、(相対パス・絶対パス問わず)ファイル名で参照しているものは書き出されない(http/https な URL で指定した画像は HTML でエクスポートする際は画像が貼られる形になるが PDF ではだめ)。Ulysses だけを使って画像を扱いたいなら TextBundle を使う以外選択がない感じだ。

Ulysses 上で TextBundle なシートを保存するたびに参照されている画像ファイルを残して他は assets/ から消されてしまう。なので assets/ の下に画像作成に使ったソース・ファイル(マインドマップファイル)を一緒に置いておくおような管理はできない。そもそもテキスト編集で間違えて画像参照を消して保存実行してしまうと、画像ファイルだって消えてしまうので、画像ファイルだってオリジナルを別で保存しておく必要がある。

TextBundle は使うのは控えた方が良さそうだ。

Marked 2 で Markdown プレビュー時に自動的に画像を探すようにした

ライティングアプリ Ulysses for Mac では画像ファイルのプレビューがいい感じじゃなかったので、 Markdown プレビューアの Marked 2 を使うことにした。

• http://marked2app.com/

Marked 2 は相対パス指定・絶対パス指定のローカルの画像ファイルや URL で指定したネットワーク上の画像もきちんと扱ってくれるので便利だ。

画像ファイルをどこにおいておくか

さて Markdown ファイルから参照している画像ファイルをどこに置いておくか。Markedown ファイルと同じディレクトリに置くのが素朴だが以下の点で却下。

• Markdown ファイルを別のディレクトリに移動する時に参照している画像ファイルを一緒に動かすのが面倒。
• Markdown で書いた日別のノートファイルがたくさんあるようなディレクトリでは画像ファイルが邪魔。

別のところにまとめて置いておくのがよさそうだけれど、そうするとパス指定の問題が出てくる。ファイル移動時の参照書き換えをするは面倒なので嫌。

どうしようかなと思っていたら、 Marked 2 のプリプロセッサ機能で画像のパスを書き換える例を発見。その記事ではローカルホストでのプレビュー時とサイト公開時とでパスが違うことの解決に利用していたんだけれど、ローカルホスト上でも応用できるな。

パス指定はプリプロセッサにやらせてしまえばいいじゃない。画像のファイル名をユニークにしておき(もともとそうしている) Markdown ファイル上ではそのファイル名だけで画像参照として書く。プレビュー時に画像ファイルをローカルホスト上で検索して見つかったパスで書き換えてやれば良いなと。

さっそく Perl プログラムとしてプリプロセッサを作成。 Markdown ファイル中の画像参照があったら、Markdown ファイルのあるディレクトリレクトリ以下および指定したパス以下のディレクトリから File:Find::find で探し、見つかればそのパスに書き換えるようにしてみた。

あ、これ便利。

画像ファイルをいちいち Markdown ファイルの近くにエクスポートするとか、一緒に移動させるとかする必要なくてめちゃくちゃいいわ。

1ファイルノートから複数ファイルノートに戻す

TaskPaper をまた使うようになったタイミングで inbox メモと整理前のデイリーノートを1テキストファイルに書くことにしたのだが、やはり複数テキストファイル(inbox メモ毎に1ファイル + 日別ファイル)スタイルに戻すことにした。

1テキストファイルでは「複数ファイルをいったりきたりする」「個別にファイルを作る=ファイル名をつける」という手間から解放されたのが良かった。TaskPaper を使えば全体をみたり特定の場所だけフォーカスインしたりできるので、まとめ作業が捗った。

一方ファイルが大きいのでスマートフォンで書き込むのに躊躇するようになった。スマートフォン上のテキストエディタで TaskPaper に合わせたインデントをつけていくのは現実的ではないので、階層を無視してとりあえずメモを書き込んでおくというのが不格好だった。1ファイルを複数デバイスで編集する機会が増えるので編集競合の危険性も高くなった。

やはり個別ファイルをガンガン作って Ulysses でザクザク整理する方が自分には合ってそう。

[ アウトライナー ] [ ノート・日記はテキストファイルに ]

Web 日誌 / Web 日記を書き始めてから20年

途中ブランクがあったりするけど、書き始めてからついに20年だ。

いつ始めたか?

個人 Web サイトを作り始めたのが1995年か1996年ぐらい。それから数年経った1999年1月19日にコンピュータ日誌として日付ベースの記事を書き始めた。

当時既に Web 日記を書いている人はいたが、まだ HTML ファイルとして直接書いている人も多かったんじゃないかな。自分は当時マクロプロセッサ m4 を通して静的 Web ページを生成していたので、当初 Web 日誌も m4 マクロで生成していた。

ハイパー日記システムが公開されたのが前年の9月、 tDiary が SourceForge.net に公開されたのは3年後の2002年2月20日であった。その翌年の1月16日にはてなダイアリーベータ版がリリース、さらにその翌年日記機能をもつ mixi がオープンとなる。

そこそこ早い時期から Web 日記 (Web 日誌)を書いていたんじゃないかな。

20年続けて得られたものは?

20年続けて得られたものは以下だな。

• 自分の20年の情報が蓄積されたパーソナルナレッジベースとなった。自分の過去の何かについてはサイト内を Google 検索すればたいがい探せてしまう。
• パーソナルナレッジベースについての知見を得た。
  • 特に個人の情報は「いつ」のことかが重要。
  • 「システムの寿命よりもデータの寿命を特に重視して設計されていなければならない」「ノート・日記はテキストファイルに」「ファイル名中の日付を先頭にする」
• ちょっぴり人の役にたった。
• ちょっぴり収入になった。

20年続けて失ったものは?

一方失ったものは時間。公開している以上、下調べしたり文章を整えたりするのにある程度時間がかかり1週間に数時間は費やしている(1日分で数時間の場合もザラ)。Web 日記を書いていなければ数千時間、他のことができていたであろう。

あ、もちろん無駄な時間だったとは思ってはいない。調べたり考えたり内省したり、日記を書き続けたから今の自分がいるんだよね。

続ける?

Web 日記は趣味だからね。

[ コンピュータ日誌 ]

プレビュー付きテキストファイル一覧表示ができる Android ノートアプリ neutriNote

テキストファイルベースでノート管理をするのに Mac では Ulysses や iA Writer を、 Android デバイス上では JotterPad を使っている。JotterPad は主にユビキタスキャプチャ用のフォルダを開いた状態にしているので、フリーノート用に使える Android アプリを別に欲しいところである。

しかしテキストエディタはいろいろ存在するのだけれど、ファイル一覧で中身をプレビュー表示できるものはほとんど無いんだよね。ノートアプリとして使うにはファイル名一覧では駄目で、中身がずらずらっと見られる必要があるのだ。例えば Google Keep の表示みたいに。

で、いろいろ探してみたところ以前から名前は知っていた neutriNote が、テキストファイルとしてデータを保存するタイプでしかも一覧表示でプレビュー表示で中身を横断的に見られそうなのでインストールしてみた。

(play.google.com/store/apps/details?id=com.appmindlab.nano より)

• neutriNote

名前なニュートリノからきているらしい。

特徴や使用感

• Markdown に対応している。良い。
• タイトル = ファイル名はいったんデフォルトで「New Note (n)」となる(テキストは設定で変更可能)。
• プレビューは3行。ほとんどのアプリがファイルの先頭を表示するのに対して、末尾を表示するというのが特徴的。追記していくことを想定した UI かな。
• フォルダ階層は提供しないポリシー。
• ノートをシェアするとテキストにタイトルも含まれる(Twitter の下書きとして使うにはタイトルが含まれない方が嬉しい)。
• ウィジェットでホーム画面にノートを表示できる(ただし neutriNote 以外で直接ファイルを削除する場合、ウィジェット表示しているとアプリが落ちるっぽい)。
• (いい意味で)変態的カスタマイズができる。例えば ~neutrinote_shortcuts という設定ファイルに date|neutriNote$ date +%Y-%m-%d-%H%M%S と記述しておくと、ノート上の date という文字列を選択してテキスト展開ボタンを押すと書式指定した date コマンドを実行してその結果で置換してくれる。

同期

neutriNote はデバイス上に指定したローカルリポジトリ(フォルダ)にテキストファイルとしてデータを保存するので、Dropbox や Google ドライブで同期できる。

neutriNote にもオプションで「neutriNote Connector+」というアプリがあるのだけれど、 Dropbox のアプリフォルダ以下だけのアクセスタイプで作られているので自分の用途に合わなかった。

ので今回は以前から使っている FolderSync Pro で Dropbox と双方向同期させることにした。インスタント同期をオンにしておけば neutriNote で変更を加えたらすぐ Dropbox に同期させられる。Dropbox 側での変更を検知して同期することはできないので別途定期同期を設定しておくとともに、 Android デバイスのホーム画面に同期開始のショートカットを置いておいた。

ちなみに neutriNote ではファイル名が ~で始まるものは隠しファイルなので同期から除外。逆に Ulysses は .Ulysses で始まる隠しファイルを作るのでこれも同期対象から除外にした。

良さそげ!

テキストファイルベースのノート管理というスタイルに超ハマる Android アプリだ。 常用ノートアプリの仲間入り!

[ ノート・日記はテキストファイルに ]