always one step forward

always one step forward

IT寄りの and/or IT以外の日常。マラソン大会/ランニング/GPSウォッチ。美術展/建築/工業デザイン。長文でもなるべく読みやすく構成する文章練習帳

"ブログ+写真" 運用の来し方行く末

はてなブログでの記事蓄積はストップし、mediumかnoteに書いていこうかと方向を決めた話。どちらにするか?ほかにも適したサービスがあるかも?はもう少し検討。

ブログ+写真運用:これまで

ブログ本文からFlickr上の写真にリンク

Flickrのembed機能で写真やアルバムごとにHTMLを取得し、ブログへ貼り付け

ブログ データ構造 写真 データ構造
はてなブログ 記事1
 写真a embed(リンク埋め込み)
 写真b embed

記事2
 写真d embed
...
Flickr set001
 写真a
 写真b
 写真c
set002
 写真d
...

なぜこんな形にしたのか?

i.e. なぜ「はてなフォトライフ」に置かなかったのか?=将来のブログ移行に備えたため

ブログを変えても、写真(の実体データ)はFlickrに置き続けることにして、

ブログ データ構造 写真 データ構造
別ブログ 記事1
 写真a embed
 写真b embed

記事2
 写真d embed
...
Flickr set001
 写真a
 写真b
 写真c
set002
 写真d
...

とすれば柔軟かと思って細々と+脈々と継続してきた。当時(7-8年前)としては間違ってはいない考え方、とは思っている

しかし振り返ると‥

時を経て記事が蓄積され+写真も増え、そんなブログ移行作業が発生し得ない(非現実的 >-< だった)ことに気づく。

自分でブログを削除しない限り、静的なコンテンツとしてWebには残るわけで

ブログ+写真運用:現在

ブログ本文⇔Flickr上の写真リンクを切り離す

先日(2018/12)あたりから、ブログ用の写真は「はてなフォトライフ」に置くことにした

写真 データ構造 ブログ データ構造
はてな
フォトライフ
トップフォルダ
 ¥yyyymmdd ...[1]
  写真a
  写真b
 ¥yyyymmdd ...[2]
  写真c
...
はてなブログ
記事1
 写真a
 写真b
記事2
 写真c
...

「yyyymmdd」は、[1]は記事1の、[2]は記事2の日付に合わせたフォルダ名

Flickr上の写真データへのリンクは用いなくなり、ブログとFlickrを完全離脱させるとも言える。シンプル。

しかし始めてみると‥

  1. はてなフォトライフ」にフォルダ作成
  2. 写真を(多くの場合は複数)アップロード
  3. ブログ編集画面で写真ごとに選択して貼り付け

‥という作業さえ面倒に感じ、あまり投稿頻度が上がらない。。

「記事に紐づく写真は、その記事本体へいきなりどんと貼り付ける」というカジュアルなーいわばSNS時代のーアクションに慣れきってしまったからかもしれない

「フォルダ作成」を省略すればよさげだけれど、同じフォルダに写真をどんどん平たくアップロードするのが、それはそれでちょっといやだなあと

ブログ+写真運用:今後

ブログ本文に埋め込む

mediumやnoteであれば、記事編集画面でつらつらと文章を書き、写真を置きたい位置にアップロード。シンプル

かつて隆盛をきわめた「WYSIWYG」時代が再来しているとも言える。

どのブログサービスにするか?

To output, or not to output, and where to output: that is the question.

「アウトプットするのかしないのか、するならどこへ、それが問題だ」

このソーシャルメディア時代にシェイクスピアがいればきっとこの台詞を書いた、かどうかはわからないけれど

検討中。noteかな?Mediumかな?

Flickrから写真データの移行:flickr downloadr

上記で検討したように、Flickrは(Proに移行せず)Freeのまま使うことにした。

「2019/2/5以降、1000枚を超えた分は、古い写真から削除しますよ」(be "at risk of" deletionなのでただちに削除します、ということではなさそう。いつ削除されてもおかしくない、のニュアンスか)

‥ということで、その期限の前に:

  1. ローカルへダウンロード
  2. Smugmugへアップロードする

ひとまず1.を実施しておく必要がある。結局「flickr downloadr」を利用してうまくいった。どうもありがとうございます。

Flickrから写真をローカルへダウンロードする方法

いろいろ調べると以下の方法がある。

flickr downloadr

A cross-platform desktop application for Windows, Mac and Linux to download (all or selected) photos from your photostream in their original size along with their description, title and tags.

この方法を選択。無償のオープンソースソフトウェア。便利だったのでdonationしました

利用手順

シンプル。ログイン後にアルバムを選択してダウンロード。下記の画面で複数アルバムを一括指定できて便利

flickr downloadr アルバム単位でダウンロード

flickr downloadr ダウンロード中

メタデータは写真画像と同じ名前、拡張子 .json で保存される

flickr downloadr ダウンロードしたデータ

上記を何回かに分け夜間実行で繰り返し、無事全アルバムをローカルへダウンロードした

Flickr 公式機能でダウンロード

アルバム単位

Album一覧からアルバムごとにzipファイル作成が可能。画面右上の通知またはメール受信で、ダウンロード可能になったかを教えてくれる。リンク先は約1週間有効 ただし、アルバムが多数だとその分手動操作も増える

f:id:masa_grant55:20190112181449p:plain:w500
Albumごとにzipダウンロード

一括ダウンロード

[Settings] メニューからリクエストし、しばらく待つとzipファイル群を準備してくれる。 ただし一連の写真画像を順にzip化しているようで、アルバム単位でない。まあこれでも親切は親切

f:id:masa_grant55:20190112175723p:plain:w400
Flicker 全写真をzipダウンロード可能

FlickrからSmugmugへ写真を移行する方法

PicBackMan

FlickrやSmugmugを含むサービスに対応。移行元/先のアカウント情報を登録し、アルバム単位で(階層を崩さずに)移行可能。ローカルへのダウンロード+アップロードの一括実施

https://www.picbackman.com/choose-plan/

500枚分は無料、どんな様子で移行できるかが自分のデータで確認できる。5000枚までなら$8.95(月額)、それ以上なら$69(年額)

MigrateMan

同ベンダーの別製品。行えることもどうやら似ている

同じく有償。課金単位が「$0.99/GB」と容量ベース。月間/年間料金のPicBackMan、従量料金のMigrateManということかも

https://www.migrateman.com/pricing/

時間や手間 vs コスト

いずれも、作業効率を考えれば価値はあるかな?トータル枚数や「面倒な移行には対価を支払ってもよい」という個人それぞれの価値観しだい。時間をかけずにぱっと移行したい時は良い選択肢と思う

Flickrから写真の削除

ローカルに全写真をダウンロード完了。ひとまず安心。追ってSmugmugへどんどんアップロードしておくことに

次は:Freeでも1000枚まではFlickrに残しておけるので、残さなくて良い写真を削除することにする

削除する写真の選択

ブログ中、いまでもアクセス数のある記事にリンクした写真は残すことにした。その他はFlickr画面上で手動削除。これはこれで結構面倒だった

写真の削除後

ついに1000枚未満となり、メッセージが赤から水色に!

Flickr 1000枚未満になった

弊害として、削除した(残さなかった)写真へのリンクがあるブログでは、下図(下側)のような404表示。まあ仕方ない。。

リンク先の写真がない場合

ここまで終わり、今後のブログ運用について整理したのでまた別の記事で