nDiki : アップロード

昨日の写真を整理するなど【日記】

今日は昨日の歩く会で撮った写真を整理して Flickr! にアップロードしたりしていました。通った場所を地図で追いながらスポット名や交差点名などを確認するのが密かな楽しみです。

先週行った伊東旅行の日記がまだ書けていないので、こちらも記憶がしっかりしているうちにまとめたいです。

今日のさえずり: 揃えると被るの違い

2016年01月09日

• 16:08 加湿器を掃除。今回は結構汚れていたなー。年末年始だったからかな。
• 21:58 あれ? Flickr の Android アプリ (バージョン 3.1) から写真をアップロードできません。
• 22:03 Xperia Z5 を再起動したら Flickr にアップロードできるようになりました。なんぞ。
• 22:07 揃えると被るの違い。

Instagram の元の写真の保存とか、音声入力とか【日記】

Instagram にアップロードした写真はオリジナルサイズでダウンロードできないのですね。アプリの「元の写真を保存」は有効にしてあるのですが、最初の何枚かは消してしまいました。

Android の Google 音声入力が最近いい感じらしいのでちょっと使ってみようと思います。Google 日本語入力の設定で「音声入力ボタン」をオンにしてキーボードに音声入力ボタンを表示しておこうと思ったのですが、ボタンが出なくて「あれ?」と思ったのですが、「キーボードと入力方法」のところで Google 音声入力がオフになっていたせいでした。周囲に人がいない道を歩いている時にメモをする時などにまずは使ってみようと思います。

オフィスでは明日が誕生日のメンバのサプライズプチ誕生日会をやりました。1月2月と3カ月続けてです。うちの部は早生まれが多いようです。みんなでメンバをお祝いする空気のある部になって良かったと思っております。

nDiki に貼る写真を Flickr ではなく同じサーバに置く

この nDiki に写真を載せる際は2005年から Flickr にアップロードしてそれを貼りつけるようにしています。これを今後は普通に画像ファイルを Web サーバ側に置くことにしました。

Flickr に写真を置いておくメリットは以下があります。

• スマートフォンから簡単にアップロードしておける。Flickr アップロード + Twitter シェアした写真をそのままあとで nDiki に貼れる。
• Flickr で様々なサイズの画像にしてくれるので自前でリサイズしなくて済む。
• Web サーバの容量を圧迫しない(当時は 容量が少なかった)。

一方デメリットとしては

• Flickr にベンダーロックインされている。長期的には一抹の不安。
• 一度画像の URL が変わったタイミングで過去の写真が一部表示できなくなっている(記事側の URL を変更していく必要がある)。今後も同様の自体があり得る。

があります。

Flickr 利用で使い勝手的には問題が無いのですが、長期的に継続する Web 日記のコンテンツとしては他のサービスに依存しすぎないようにした方が良いということで、今後は普通に Web サーバに置くことにしました。

そうするとどのサイズの画像ファイルを用意するかを改めて考える必要が出てきました。

画像サイズ

今までは Flickr で生成されるから適当そうなもの(たいがい長辺 500px のもの)を選んで貼っていました。今後は自分で適切なファイルを作ってアップロードすることになるので画像サイズについてちょっと見直してみました。

Bootstrap 3 でのサイトの幅の見直してコンテナを 970px までに

Bootstrap 3 だと広くても幅 1140px (1170px - 30px) なので画像幅もこれだけあれば十分です。しかし考えてみると nDiki は1カラムなのでラージデバイス(≥1200px)向けのコンテナ 1170px はいささか広すぎます。ということでいったんミディアムデバイス向けのコンテナ 970px までしか広げないようにしました。

 @media (min-width: 1200px) {
     .container {
         width: 970px;
     }
 }

写真は基本 max-width: 100% の .img-responsive で表示しているので、これで最大 940px 幅で表示されることになります。

表示される写真の高さは最大 480px に

幅 940px だと 4:3 なら高さは 705px、3:2 なら高さは約 627px になります。13インチMacBook Pro 上の Google Chrome でこのサイズの写真を貼るとほぼ縦いっぱいになってしまいます。記事中の写真では 480px ぐらいまでかなという印象でした。ということで

 max-height: 480px;

としました。

これだと 4:3 なら 640x480px、3:2 だと 720x480px の画像サイズがあれば十分なことになります。縦位置だと 3:4 で 360x480px、 2:3 だと 320x480px です。

画像ファイルの画像サイズは長辺 1200px に

これで 640x480px (4:3) や 720x480px (3:2) にリサイズして Web サーバに置けば現時点では過不足ないということがわかりました。

ただこれだとデバイスの変化でサイトデザインを見直す時がきた時に解像度不足になってしまいます。Bootstrap のラージデバイス向けのコンテナサイズを考えていったん長辺 1200px で画像ファイルを用意することに決めました。

ついでに .pull-left と .pull-right の画像幅も調整

写真を左右に寄せた際に現状テキスト部分が狭くなりすぎることがあるのでこのあたりも合わせて今回調整しました。

 .img-responsive {
     display: inline-block !important;
     max-height: 480px;
 }

 @media (min-width: 768px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

 @media (min-width: 992px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

 @media (min-width: 1200px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

Emacs 25.2 の make 失敗とか【日記】

Emacs 25.2

新しい開発環境に入っている Emacs が 24.3 で helm, helm-ls-git, magit パッケージが使えません(Emacs 24.4 以上が必要)。ということで最新の Emacs 25.2 を入れようかと思ったのですが make 失敗。randomize_va_space が 2 だと駄目のようですが、EC2 + Docker コンテナ上でどうするのが最適なのかな。

Qiita:Team

Qiita:Team にアップロードした画像を自分で削除する手段が用意されていないようで気持ち悪い。こまめに図を更新したい時に気が引けて嫌です。うーん。

今日のさえずり: 自動的に消灯しないトイレ良い

2017年05月25日

• 11:00 自動的に消灯しないトイレ良い。
• 15:00 Qiita:Team はやはり画像削除できなさそう。こまめに修正したい画像をアップロードするの気が引けるな。
• 20:15 randomize_va_space が 2 で Emacs 25.2 の make がコケた。

撮り直したい写真を Google フォトにアップロードしておく試み

撮った写真を整理していると、(その瞬間しか撮れなかった写真はさておき)「ああ、撮り直したいな」という写真が出てくる。その時はまた撮りに行こうと思うのだけれど、別の日に「さて今日は写真をどこに撮りに行こうかと」考えた時にはなぜか思い出せない。

「撮り直し」アルバムとスポットリストを作っていつでも見られるようにしたらどうかと以前から思っていたので、そういう写真をひとまず Google フォトにアップロードしてアルバムに入れておいてみることにした。

Google フォトに入れておくと便利な点

いい精度で撮影場所を推定してくれるのであとでどこで撮ったか思い出しやすい。検索で特定の場所の近くで撮影した写真を探すこともできるので、撮りに出掛ける場所を考える時のも便利。

どこでも閲覧できるというのも Google フォトを使うメリットだ。

Google フォトに入れておくと不便な点

「撮り直したい写真」を入れておくということは Google フォトがちょっと残念な写真だらけになってしまうということ。

スマートフォンでたまに撮った写真のバックアップとして自動的にアップロードする設定にしている以外は今はほとんど使っていないので、とりあえず問題ないのだけれど本格的に Google フォトを使う気になった時にちょっともやもやした気分になりそう。

Google ドライブではテキストファイル作成時の拡張子で全文検索対象になるか決まるみたい

Google ドライブにあるノートテキストファイルを参照したくなり、そこに必ず書かれていると分かっている単語で検索してみたけれど検索結果に出てこず「あれっ?」となった。検索結果に出るテキストファイルと出てこないテキストファイルがある。

全文検索対象になっていないテキストファイル

違いを調べたところ Web 版 Google ドライブでテキストファイルの詳細を右側に表示した際に「縮小されたサムネイル」が表示されるものは全文検索対象になっていて、表示されないものは全文検索対象になっていないようだ。

でテキストファイルで「縮小されたサムネイル」が表示されるかどうかの違いだけれど、どうやら作成時(ローカルホスト上でファイルを作成して「バックアップと同期」で Google ドライブに最初にアップロードされる時を含む)に、拡張子が txt か md (Markdown ファイル)かで決まっているような挙動だった。最初に txt で作った後に md に変更しても全文検索対象だし、逆に最初に md で作ったファイルは後で txt に変更しても全文検索対象にならない。

Google ドライブに置くすべてのノートテキストファイルを拡張子 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 みたいにローカルファイルシステムとの同期を前提とした設計で出発していないのか特殊な仕様が多いので、時々ハマるんだよね。

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

Google Nest Hub をずっと欲しかったデジタルフォトフレームに

スマートディスプレイ Google Nest Hub は使用していない時にフォトフレームとして写真を表示させる機能がある。Google フォト上にアルバムを作ってそれをフォトフレームとして選択すればあとは自動的にランダムに表示してくれるので楽ちんだ。

10年以上前にデジタルフォトフレームが欲しいと思いつつ、単独の製品としてはそこそこの値段だったので買うには至っていなかった。その頃のは表示したい写真をメモリカードに入れてデジタルフォトフレームに挿すといった手間が昔は必要だったから、10年前に買ったらすぐに飽きていたかもしれない。

さっそく Google フォトに500枚強写真をアップロードして設定してみた。

リビングにデジタルフォトフレームがあると、思い出の写真を見てその時の記憶が蘇ってきて良いね。ただ実際に表示させてみると、必要以上に気を引かれてしまうという心理的な負担を感じることも分かってきた。新しい写真が目に入るたびに、何が写っているのがしっかり見ようとしたり、その時の記憶を引き出そうとしたりして脳の注意がそちらにもっていかれてしまう。初期設定の1分毎の切り替えだとさすがに参っちゃいそうなのでいったん3分毎に変更してみた。

気を引きすぎないように注意する必要があるけれど、やはり写真が表示されているというのはいいな。 Google Nest Hub にして良かった。

Google フォトはスマートフォンと同期しない方が便利では

Pixel 4 では Google フォトの「バックアップと同期」を OFF にした方が運用しやすい(というか OFF にしないと運用できない)のではと閃いて OFF にした。 Google フォトをうまく使えていなかったの、Google フォトの「バックアップと同期」を ON にすると「選別した写真」と「選別されていない写真」が混在してしまうのが問題点だったんだなと。

Pixel 4 で撮った写真を MacBook Pro に移して Lightroom Classic で選別・現像/調整しているので、選別・調整されていない写真がどんどん同期されてしまうと、わけが分からなくなってしまうという。

ちなみにデバイス上の写真の一時的なバックアップに Google One の「写真と動画」のバックアップ機能が使えれば嬉しいんだけれど、薄々思っていたとおりこれは Google フォトへの「バックアップと同期」と同じものだった。Google One の「写真と動画」のバックアップ設定の変更はそのまま Google フォトと連動(オン/オフ、アップロード サイズ)していた。

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 上の写真を表示するようにしてみたところうまくいっている感じ。

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

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