portal shit!

LDR が再び終了するとのこと。

RSS 、確かに昔に比べたら使わなくなった。ソーシャルメディアが情報の流入口になってる。

そもそも自分自身も周りの人もブログの更新頻度が落ちてる。いまも精力的にブログ書いてる人はとても珍しいと思う。長々とブログに書かなくても 140 字のツイッターに 2, 3 投稿すれば満足できるのかもしれない。むかしはメインのコンテンツがブログだったのに対していまはソーシャルメディアになってるので、コンテンツの発信と受信がそのソーシャルメディア内で完結してしまう。ツイッターやフェースブックを RSS リーダー経由で読む人はまずいない。というかフィードが提供されていない。

加えて、情報収集も分野ごとにハブとなる人がいて、その人経由で仕入れるのが効率的になった。前は話題になったブログがあったらみんなでそのブログのフィードを購読してたような感覚あるけど（ LDR ではフィードの購読者数が表示されてた）、いまは目利き的な人がいてその人のソーシャルネットワーク（はてブ、ツイッター、ヘェースブック）経由で情報を仕入れる感じ。 Twitter Card とかオープングラフプロトコルとか出て来たのも大きい¹。 RSS リーダーではなくソーシャルメディアが情報が集まる場になってる。

とはいえ一部の目利きの人たちは RSS リーダーとフィードの仕組みなくして効率的に情報収集することはできないので今後も利用者がゼロになることはないと思う。そういう情報収集マニアな目利きの人たちに対して課金しないと RSS リーダーは収益化できないだろう。だとしたら目利きから情報収集している我々は目利きの人たちに対して投げ銭的なことができれば良いんだけど。

古い MacBook Pro の SSD がいっぱいになり写真が取り込めなくなっていたので外付け HDD を購入して写真は外付けに退避させた。母艦 Mac の SSD の空きが少なくなってきてるせいで写真を撮ることを控えるようになってしまっていたが、 3TB の外付けにライブラリを移したので本体側の空き容量を気にせず写真をばしばし撮れるようになった。これをきっかけに、いくつかのブログで目にしていた Google Photos を試してみたけど確かにこれは便利だった。Apple の写真（ Photos.app ）と比較しながら思ったことを書いてみます。

Google Photos への写真のアップロード

Google Photos を使うためにはまず Google Photos に画像をアップロードしないといけない。ブラウザーからちまちまアップロードする方法もあるが、 アップロード用のソフト が用意されているのでそれを利用した。名目上はバックアップということになるらしい。 20000 枚近い画像をアップロードするのに二日くらいかかった。アップロードに失敗することもあるけど、失敗したアップロードがあったときには通知してくれてリトライもできるのでおそらくすべての画像をアップロード出来たのではないかと思っている。楽ちん。

写真の内容を文字列で検索できる

こんな感じで「肉」と入力すると肉っぽい写真が表示される。画像認識処理をしてあって、個々の画像に対してタグ付け的なことがしてあるのだろう。

試しに Photos.app の方でも「肉」で検索したら肉の写真が表示されるようになってた。なんと Photos.app の方でも画像認識処理を行っているようだった。全然話題になってない気がする…。ドーナツの写真がヒットしているのはご愛敬。

Google Photos では「ギリシャ」で検索するとギリシャの位置情報が付与されている写真に加え、どう考えてもギリシャにしかない建築物（アテネのパルテノン神殿など）が写ってる写真を検索結果に含めてくれる。賢い。

さすがにこのような機能は Apple の Photos.app の方にはないみたい。「ギリシャ」で検索しても、ギリシャに行ったときに iPhone で撮影した位置情報付きの写真しかヒットしない。キーワードと写真の関連性の判定アルゴリズムは検索エンジンをやってる Google の方にアドバンテージがあるみたいだ。

写真のグルーピング

Google Photos には「アシスタント」というタブがあって、勝手に過去の写真を漁ってグループにしてくれたり音楽付きのスライドショーにしてくれて、「金曜日の夕方」や「土曜日の午後」みたいなエモーショナルなタイトルをつけて煽ってくる。

機械がやってくれてる割には良くできてるとは思うけど、人間が選んだアルバムに比べたら素っ頓狂なセレクションが多いし、頻繁に Push 通知が来てちょっとうざい。「阿蘇旅行」みたいなアルバム作って通知してくるけど「旅行じゃないし、阿蘇に住んでたし」という気持ちになる。写ってるものの内容からアルバム名を考えて付けてくるのは賢いけど、わかりやすいものが写ってないとだめで、たとえばこのアルバムは大分の温泉とかいろんなところに行ったけど、最後にちょっと立ち寄った熊本城の写真がわかりやすいので「週末、熊本市にて」というアルバム名になってしまっている。このように Google Photos にはやり過ぎ感がある。

※更新2021-01-24: この機能は「おすすめ」という名前に変わったようだ。 https://photos.google.com/foryou で表示される。プッシュ通知も送られてこなくなった。

Apple の Photos.app の方にも「メモリー」というメニューがあって似たような機能はあった。ただこちらは勝手に音付きのスライドショーを作ったり Push 通知したりはしてこない。控えめな印象。一年前の今日なにやってたかとか、直近の一ヶ月でどんな写真撮ったかだけが表示される。

Apple の Photos.app の方にあって Google Photos にない優れた機能としては、 GPS 情報が付与されていない写真（一眼レフで撮った写真）も大体どの辺で撮ったのか判定してグルーピングしてくれる機能がある。おそらく位置情報付きの写真の GPS 情報を参照して近い時間に撮影されたものはきっとこのあたりにいたに違いない、という感じでまとめてくれてるんだと思う。こんな感じ。

↑の写真で 9 枚は一眼レフで撮影していて GPS 情報がないけど、同じ時間帯に iPhone で撮った写真は位置情報が付与されているのできっと長崎で撮ったのだろう、ということでまとめてくれている。この機能は旅行のときの写真を見るときに地味に便利。 Google Photos にもこの機能はついて欲しい。

写真をグルーピングすることに関しては、 Google Photos はアグレッシブ、 Apple Photos.app は控えめ、という印象を持った。というか Google Photos は攻めすぎな印象。アルバムのタイトルがエモ過ぎるので嫌いな人は見なくなりそう。

過去の写真の閲覧しやすさ

何より Google Photos が Apple Photos.app より優れているのは全ての写真をネットに繋がる限り無料で閲覧できることだと思った。 iCloud で同じことやると年間数万円お金払わないといけない。最近は仕事以外でパソコンを使う頻度どんどん下がって行ってて（自分だけじゃなく世の中のみんながそういう傾向にあると思う）、携帯電話を使う時間がどんどん長くなってきてる。過去の写真を見るのにいちいちパソコンを開かないといけないのはしんどい。手元にある携帯でいつでも過去の写真が見られる Google Photos の方が圧倒的に優れていると感じた。 Apple TV にミラーリングすれば家族全員で写真を見ることもできる。 Photos.app の iCloud フォトストリームではお金を払わない限り 1000 枚までしか共有されないので Apple TV 単体で写真を見ると最近の写真しか閲覧できない。 Google Photos を知る前はそれでも楽しかったんだけど、平日の夜の何気ないタイミングで携帯を眺めていて 2 年前の旅行の写真が目に入り、テレビに映して旅行の思い出に浸る会を緊急開催みたいなことが Google Photos では可能になる。これは本当にすごいし、写真を撮りたいと思うようになった。閲覧・整理環境に課題があると「どうせ撮っても見ないし…」という気持ちになる。

Apple はなぜ先にこのような体験をユーザーに提供できなかったんだろう。ユーザーの画像を預かる、という点では iCloud で Google よりも先行していたはずなのに。

Apple に期待すること

総じて Google Photos が勝っていると思う。一度 Google Photos を使ってしまうと、 Apple の Photos.app で写真を見るという気持ちにはならないだろう。

Apple Photos.app はローカルで動くソフトウェアの強みを活かして、写真の編集方面で強くなって欲しい。 Google Photos の写真編集機能は貧弱だし、一度アップロードした写真を手元にダウンロードして編集して再度アップロードするのもだるい。何も Photos.app 本体の編集機能を強力にしろと言ってるわけではない。画像を外部の編集ソフトと受け渡しできるだけで良い（ iPhoto から Photos.app になったタイミングで外部のソフトを編集・現像ソフトに指定できなくなったり、ドラッグアンドドロップで画像を書き出せなくなったが、そっち方面の機能を充実させて欲しかった）。

画像認識だとか機械学習みたいなのは、ユーザー自身の Mac の中でちびちびやってもサーバーサイドでいっぱいコンピューターを並べて並列処理でだーっと実行してるだろう Google には勝てない。そういうので Google とやりあうのは良策ではない。

そして欲を言えば Aperture の開発を継続して欲しかった。 Lightroom のために Adobe に毎年 12000 円払える人は限られている。お金以外にも Apple が作ってる現像ソフトという安心感が Aperture にはあったんだよなぁ。 Adobe のソフトのジャバジャバした感じは好きになれない。

合同勉強会 in 福岡という勉強会があって、 Nulab の人やクラスメソッドの人たちが福岡に来て発表するということだったので行ってみたいと思ったけど参加者枠が埋まってたので LT 枠で申し込んで行ってみた。まえブログに書いた BitBar の話をした。

以前一緒に仕事していた Rudolph Miller 先輩がインタビューで「勉強会は勉強しに行くところじゃなくて自分が普段勉強してることが合ってるか確認しに行くところ」みたいなことを言ってたけど、今回は普段勉強してないことがありありとなった感じでやばいなと思った。皆さん AWS とか Azure とか Terraform とかに詳しすぎる。きしだなおきさんの機械学習についての発表とかさっぱりわからなかった。平川 剛一さんの Server-side Swift の話は面白かった。 Server-side Swift の開発、 Apple じゃなくて IBM が主導しているそう。ぼちぼち Web フレームワークなんかもできてきてるみたい。

LT は皆さんレベルが高く、ネタに走りつつも技術的に高度な内容で自分の LT が一番しょぼかった。発表もうちょいうまくなりたい。

puma はメモリ食い

puma にして喜んでたけど二時間後くらいに NewRelic で様子を見てみたらメモリ 90% 以上消費してて swap ファイルもめっちゃでかいのができてて暴発一歩手前になってた。

一旦 puma をシングルモードからクラスターモードに変えて puma_worker_killer を導入し、 worker を定期的に再起動するようにした。ただ restart 後のメモリ増加傾向は変わらない。

引き続き NewRelic で様子を見ていると Python2 が一番メモリを食っている。このブログは Syntax Highlighting に Python の Pygments を pygments.rb 越しに使っている。これまで unicorn の worker プロセス 2 個で動かしていたときには最大でも Python のプロセスは 2 個で事足りてたけど、 puma にして 16 スレッド（ puma のデフォルト）が起ち上がるので、 16 個の Python プロセスが起動していたっぽい。

これは意味ないなということで以前利用したことがあった Pygments の Ruby 移植版である rouge に変えてみることにした。こちらは Ruby なのでスレッドが別プロセスを起動してメモリ爆発ということにはならないと思われる。

puma_worker_killer と Pygments 置き換え後半日様子を見たが、これでメモリ消費量爆発ということはなくなった。

sidekiq でスレッドを増やしたときにも似たようなことを経験したけど、 Ruby から外部のプロセスを起動するようなプログラムを書いているときにマルチスレッドで処理をさせると、 Ruby のプロセスは増えなくても外部のプロセスがめっちゃ増えてそのせいでメモリあっぷあっぷになったり CPU の使用率が高まったりする。マルチスレッドプログラミングのご利用は計画的に。

異なるワーカー間でセッションを継続できない？

puma をクラスターモードにしたことで別の問題も発生した。なんとセッション情報が異なるプロセス間で共有されていないっぽい。なのでログインしてすぐに再ログインを求められるようになった。これは不便。原因を調査するには時間がかかりそうだったのでシングルモードに戻してみることにする。

まとめ

1. デフォルトの 16 スレッドでは puma は unicorn に比べてメモリを沢山消費する可能性がある
2. Ruby から外部のプロセスを起動するような処理に注意
3. puma のクラスターモード（ master worker モデル）でセッション情報がリセットされる問題に遭遇

追記

セッション情報が異なるプロセス間で共有されていない

これはちゃんと設定があって、 puma.rb に preload_app! を記述すればよかった。

If you're running in Clustered Mode you can optionally choose to preload your application before starting up the workers. This is necessary in order to take advantage of the Copy on Write feature introduced in MRI Ruby 2.0. To do this simply specify the --preload flag in invocation:

# CLI invocation
$ puma -t 8:32 -w 3 --preload

If you're using a configuration file, use the preload_app! method, and be sure to specify your config file's location with the -C flag:

$ puma -C config/puma.rb

# config/puma.rb
threads 8,32
workers 3
preload_app!

-- https://github.com/puma/puma#clustered-mode

これでプロセス間でセッション情報が共有されるようになった。

ブログの管理画面にファイルアップロード機能をつけてみた。 GitHub の Issue みたいにドラッグアンドドロップでアップロードしてくれる。こんな感じ。

いまのところ埋め込みフォーマットは Markdown にしか対応してない。

Lokka は heroku とか PaaS を使うことを前提に作られているのでファイルをアップロードする機能が提供されてこなかった（ heroku は永続的なファイル書き込みができない）。 heroku で動かしている人でも使えるように Amazon S3 に上げるようにしてみた。 AWS のアカウント作成とかが必要なのでレンタルサーバーに設置してある WordPress にファイルアップロードするのに比べたら敷居が高いけど、設定するのは1回だけだし全くアップロードする手立てがなかったこれまでに比べたら劇的に快適になるはず。自分で使ってみたけどめっちゃ便利になった。

ファイルアップロード、ちゃんと作るなら Paperclip みたいにファイルのチェックを厳密に行なわないと危ないと思うけど、管理画面から上げるの前提なのでチェックなしで雑にアップロードできるようになっている。 AWS の token 系の設定画面を作ったら Lokka 本体に Pull Request 出します。

なお一つ前の記事でアプリケーションサーバーを puma に変更 - portal shit!というのを書いたけど、このファイルアップロード機能がうまく動かなかったので unicorn を捨てたのだった（ pow で動かしている環境や bundle exec rackup して WEBRick で起動しているサーバーではちゃんとアップロードできる）。なぜか unicorn で multipart/form-data な POST リクエストを rack アプリケーションに適切に渡すことができず EOFError が発生してしまう。

仕事で unicorn で動いてるサーバーにファイルアップロードする仕組み入れたことは何度かあるけどこんなエラーになったことはなかったのになぁ。謎い。

ブログのアプリケーションサーバーには unicorn を使っていたのだけど puma に変えてみた。

2011 年から使っていたようなので丸 5 年は unicorn を使っていたことになる。 puma はスレッドセーフにしないと死ぬ、ということは聞き及んでいたのでおそるおそる変えてみたけどいまのところ問題なさげ。

手元で確認したときには scss のコンパイルで怪しい雰囲気があった（特定ページにアクセスしたあとレスポンスを返さなくなってしまう）ので 0.12.7 だった compass のバージョンを 1.0.3 に上げてみたところ問題が解決した。結果オーライということで深追いはしてないけど、リポジトリを見に行ってみたらメンテナンス停止しているようだった。最近はフロントエンドは JavaScript でやるのが当たり前ですもんね。

Lokka のフロントエンドは 2010 年頃ナウかった Ruby ベースの技術が満載で最近の傾向とは異なるので、フロントエンドで利用してる gem がメンテされておらず Ruby のバージョンアップ時のボトルネックとなってくることが考えられる。この前 Ruby 2.4.0 で動くか素振りしてみたけどダメだった。padrino-helpers 、 slim 、 haml 、 coffeescript （この機能は自分が追加した）あたりとどういう風に折り合いを付けていくか考えないといけない。

iPhone からブログ書くときに画像もアップロードしたいと思って iPhone から S3 にアップロードできるやつを調べた。 Lokka にはデフォルトでは画像をアップロードする仕組みないので自分の場合は手動で S3 に画像をアップロードするか Flickr に上げて参照するようにしてる。 iPhone からだと Flickr に上げても embed 用のコードを取得できない（ Flickr の iPhone アプリでもモバイルサイトでも embed コードは表示されない）ので、 iPhone から S3 にアップロードするのが最適解となる。本当は投稿画面から S3 にダイレクトアップロードできるような仕組みがあればいいんだろうけどまだやれてない。そのうちやりたい。

で、 iPhone 用の S3 クライアント探してたんだけど、無料のやつはたいていウェブサービスになってて、複数のクラウドストレージを一元管理できるとかそういうやつだった。 AWS の Access Key Id と Secret Token を第三者に渡して万が一それが流出したら一瞬で巨大 EC2 インスタンスいっぱいたてられて Bitcoin 掘りに利用されてクラウド破産しそうだと思った。こういうの使うにしても AWS のルートアカウントではなく S3 だけにアクセスできる IAM アカウントを使うべきだと思う。面倒くさいと思ったのであきらめて 1200 円払って Panic の Transmit の iOS 版を買った。インターネットでも金がない者や情弱が危険に身を晒さなければならない。

Transmit 自体は良くできてて便利。 Mac ではケチって Transmit よりも安い ForkLift ってのを使ってるけど、S3 にアップロードしてあるファイルの URL 取得するときにバケットに独自ドメイン当ててあったら独自ドメインの URL で取得してくれたりと Transmit の方がおもてなしされてる感がある。細かいところが親切。ブログ用の画像のアップロード以外にもいろいろ使い道ありそう。

Panic, Inc.「Transmit」 https://appsto.re/jp/IPUR2.i

2019-09-22 追記

残念なことに Transmit は開発を終了していた。儲からないのだそう。 35,000 ドルの売上では人件費の半分も回収できないとのこと。