2016年にウェブ縄文時代がどうこう書いたけど最近どうやらウェブ縄文時代が本当にきつつあるみたい、と書こうとしたら既に morygonzalez さんが書かれていた のであまり書くことはない。縄文時代というか、個人サイトへの回帰という話だけど、観測範囲のブログやら日記がASPホスティングから個人サイトに移行したりしている。
知り合いとチャットしていて教えてもらったけど、国内だけの事象というわけではないみたいで、今年の6月には The Return of the 90s Web という記事が書かれていた。不思議な潮流。
2017年に個人サイトは終わってしまったのかと書いたことがあるけど、終わってないかもしれないので嬉しい。このエントリでも触れてるけどASPホスティングの個人ブログも、セルフホスティングの個人サイトも境界は技術的には曖昧で、しいていえばコンテンツを自分で所持しているといえるかどうか。「個人サイト」は閲覧者的には技術的に区別はつかず、どちらかといえば誰のブランドで発信されているかという印象的なものと思う。
手元の NanoPi NEO2 が、証明書エラーでどうしても https 通信が不可能に。
Ubuntu 16.04 なのでそれほど古いOSというわけではない。証明書関係だろうと思いいろいろやってみたがうまくいかず、これは他の原因ではないか？と思って date したら 2016 年だった。知らないうちにリブートして、RTC を持たないため時刻設定がまきもどったようだ。
$ sudo apt-get install ca-certificates $ sudo update-ca-certificates -v $ curl https://google.com curl: (60) server certificate verification failed. CAfile: ./cacert.pem CRLfile: none More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
今後こういうことが起きないよう ntpd を入れた
sudo apt-get install ntp
Google Photos が発狂してからと書いてから、いろいろ見積って画像をセルフホストすることに決めた。とにかくアップロード機能はあとで作るとして、現状の画像が表示されていない状態を是正しなければならない。つまり Google Photos に上がっている画像のうち、日記で使われている画像をこのホスト上にコピーして配信する必要がある。
まず Google Picker API 経由で取得した media の id や URL と、Google Photos API は一切互換性がない。もともと念のために Picker 経由で取得した ID っぽいものは保存していたのだけれど、これはまったく使えない。よって、Google Photos 上の全写真のメタデータをすべて取得し、ファイル名マッチによって画像を特定 (つまりファイル名→Google Photos mediaId のマッピング) していくことにした。
Photos library API は 10000req/day が quota。0.1req/sec 程度でしかアクセスできない。そのうえ、item リスト API は 100items/req しか取得できない。つまり、1日で取得可能な item 数は100万件にすぎない。が、個人日記程度なら十分なので、一気に全メタデータを取得するスクリプトを書いて、1行に1つの mediaItem 形式のJSONとなるようなファイルをつくった。
実際にメディアを取得するリクエストは 75000req/day できるが、library API で取得できる、メディア実体を取得するための URL である baseUrl は60分で期限切れになる。全メタデータを取得したときの baseUrl は基本的に使えないため、ダウンロードするスクリプトではあらためて batchGet API を呼び、baseUrl を取得するようにした。
日本語文字列のファイル名が Google Photos 上では分解されて正規化された状態だったり、API 経由ではそうでなかったりで困った。結局 NFC して常に正規化状態で扱うようにした。
ハマったということではないが、Google Photos の library API 類はレスポンスが結構遅く、オンデマンドにこれにアクセスして実体ファイルへリダイレクトするのは結構厳しいと思った。
画像まわりを好きにできるようになったので、できれば webp メインにしたい。ただ、ファイル管理やバックアップまわりでやることが増えるので、面倒くさい。
それにしてもウェブサービスのAPIを組合せて Web 2.0 の時代はどこへやらで、かつてAPIを提供して好きにしてくれとしていたサービスもどんどん渋くなり、サービス存続が信用できないケースが多くなって全部自分でホストするみたいな原点回帰をしつつある。
ASP のブログサービスを使えばそのへんの面倒くさい実装は自分でやらなくてすむが、じゃあそのASPのサービスはいつまで続くのか？という話になるし、貧乏はとにかくつらい。