portal shit!

hitode909さんの日記を読んでたら Eye-Fi を買ったと書いてあって、hitode909 さんのツイッターに iPhone のカメラではなく GR とかで撮影したと思われるやたら高画質なラーメンの写真が投稿されるようになってた。自分も同じようなことやってみたいと思って Eye-Fi を買った。

iPhone 3G が出た当初から、というか iPod がカラーになったばかりの頃から、一眼レフで撮った写真をその場ですぐ iPhone とか iPod に取り込んで人に見せたいという欲求があった。しかしそれを実現するためには訳の分からないアダプターを買って常に持ち歩いたりする必要があってそんなガラクタを持ち歩くのは耐えられなかったので導入しなかった。

Eye-Fi 自体には以前から興味があったけど、普通の SD カードと比べると高すぎたので微妙だと思っていた。しかし上記のようなカメラの写真を iPhone に取り込む機能に加え、Eye-Fi Pro を買うと GPS ユニットなどがなくてもジオタグを写真に付加できると知り、高いなぁとは思いつつも古い SD カードが不調だったこともあり、えいやっと購入してみた。しかし期待したような効能は得られなかった。というか買うならジオタグ付与できないバージョンの Eye-Fi Mobile で充分だった。

Eye-Fi Pro と Eye-Fi Mobile の機能の違いだけど、概ね以下のような感じらしい。

Pro の方が高機能で良さそうに見えるんだけど、ジオタグ付与も RAW 対応もパソコンへの転送もかなり微妙だった。というのもカメラからスマートフォンへ転送する機能（「ダイレクトモード」と言うらしい）を利用すると、ジオタグが写真に付与されない仕様らしい（撮影してもジオタグがつきません。 | Pro X2よくある質問 | サポート << Eye-Fi Japan）。ジオタグを付けられるのは、周囲に Wi-Fi の無線がいっぱい飛んでる場所で撮った写真を、Wi-Fi でパソコンへ転送する場合のみとのこと。自分としてはカメラからスマートフォンに転送してくれる機能が一番欲しくて Eye-Fi を買ったので、それを犠牲にしてジオタグを付与する意味はない。

ダイレクトモードを使うか Wi-Fi 転送するかは、Eye-Fi の設定用のソフトを Mac にインストールして設定を行い、Eye-Fi カードに覚えさせる必要がある。つまり出先ではダイレクトモードでカメラからスマートフォンに転送し、Wi-Fi のある自宅では Wi-Fi を経由してパソコンにデータを転送させるというような使い方ができない。となると Wi-Fi でパソコンへ転送する機能も使えるようで使えないということになる。

使ってみて分かったのだけど、ダイレクトモードでは Eye-Fi カードが Wi-Fi ネットワークを作成し、iPhone はそのネットワークに接続して画像のやりとりをする。一方、自宅で Eye-Fi から Mac に Wi-Fi 転送する場合は、Eye-Fi は自分でネットワークを作成するのではなく、自宅の Wi-Fi ネットワークに参加して Mac と画像をやりとりするかたちになる。従ってダイレクトモードと Wi-Fi 転送を両立させることができないようだった。

加えて Eye-Fi の RAW 対応が微妙で、Nikon RAW （.NEF ファイル）はダイレクトモードで iPhone に取り込むと非常にサイズの小さいサムネイルの TIF 画像に変換されてしまい、まともに閲覧することができない。なので結局自分は一眼レフ側で RAW + JPEG を保存するように設定し、 Eye-Fi では JPEG 画像のみ転送するような設定にしている。

この辺の事情は以下のブログに詳しい。

Accès refusé

www.kishin-design.com

以前だったら何かものを買う際は事前に徹底的にリサーチしてから買っていたのに、iPhone 5 を買ったときの記事に書いたように、おっさん力が高まってきてよく調べもせずデジタル製品をほいほいと買ってしまって後悔することが増えた。こうやって情弱おじさんになっていくのだろうなと危機感を強めている。

まとめると、Eye-Fi Pro はゴミなので買ってはいけない。カメラからスマートフォンへの転送が目的な人は Eye-Fi Mobile で充分。ジオタグ目的の人は Eye-Fi Pro なんかに手を出すよりもちゃんとした GPS ユニット買った方がいい。

一眼レフで撮った写真を iPhone に取り込んで、給料日に焼き鳥屋に来てビールを飲んで感極まってる様子などをツイッターでなうすること自体は楽しいので皆さんもやると良いですよ。

給料日の様子です pic.twitter.com/bLuu49yZ2d

— ケツがオワコン氏 (@morygonzalez) August 9, 2013

会社で HHK Pro を使うようにした - portal shit!

一昨年、会社を変わったときに Happy Hacking Keyboard Professional 2 を買った んだけど、貧乏性のためなかなか会社に持っていって使うという気にならず、会社では...

www.portalshit.net

結局 Happy Hacking Keyboard を自宅用にも買って、家でも会社でも Happy Hacking Keyboard 使ってる。会社で墨を使って家ではホワイトを使っている。キーの押し心地は何となく高級感のある墨よりもプラスチッキーなホワイトの方がマイルドな感じがして良い。しっとりした感じがする。墨はスカスカ感がある。

ホワイトを気に入って使っていたら、キーを押し込むとき本体左下部分がミシミシときしみ音をたてることに気がついた。1万8千円もするのにひどいなぁと PFU に問い合わせたら交換品を送ってもらえた。

全般的に Happy Hacking Keyboard 素晴らしいと思う。みんな買えば良いと思う。

キーボードのことばかり考えてるとそのうち Kinesis とか欲しくなりそうな気がして怖い。

追記

結局交換品もミシミシ鳴る。これは仕様だと思って諦めるしかなさそう。会社で使ってる墨はしっかりしてるんだけどな。

2月に車を買った。スバルインプレッサの中古。車、維持費高いけどやっぱりあると便利だと思う。生活圏広がるし、これまで行けなかった糸島（福岡の湘南みたいなところ）の農産物直売所に行ってうどんを食べたりすることもできる。

子どもが生まれるとやはり車がない生活が原理的に不可能な気がしてくるようになった。子ども服を売っている店はそもそも車でしか行けないような場所にあることが多い。意外と都会の真ん中で子ども服を扱ってる店はない。ユニクロも赤ちゃん服は売ってない。百貨店に行けば何でもあるので都会の真ん中にも子ども服あると言えばあるんだけど、当然のことながら異常に高い。百貨店には庶民が買えるようなやつは売ってない。子ども用品を激安価格で売っているチェーン店に西松屋というのがあるけど、例外なく郊外で営業してる。安く子ども用品を揃えようとしたらどうしても車で西松屋に行くしかない。

そもそも子ども用品はかさばることが多く（おむつ、ミルクなど）、電車＋徒歩で行けるような場所に店があったとしても買った品物を持ち帰るのが非常に難しい。以前、電車とタクシーで西松屋に子ども用品を買いにいったことがあるけど、子ども用の風呂桶などが大きすぎて手で持ち帰ることができず、同じ市内なのに宅急便で家まで配達してもらって送料が2000円くらいかかった。そのほかにも駅からタクシーでショッピングセンターをはしごしたりで、一回の買い出しで交通費・送料だけで5000円くらいかかったことあった。

また公共交通機関での移動は公共交通機関に都合を合わせないといけないのが辛かった。地下鉄のホームから地上への上り下りや高速バスの乗り降りは結構きつい。時間も電車やバスに合わせないといけない。子どもがうんこしたからといって高速バスで移動している最中におむつを替えるわけにもいかない。車ならこういう問題があらかた解決される。

以上のような理由で車を買った。

車はカーセンサーとかで調べて実物を見に行ってから決めた。中古車屋は非ディーラー系とディーラー系の両方に行った。非ディーラー系は飲み物を出してくれたりゆったりとしたソファがあったりして店の作りは贅沢だと思ったけど、車の値段が詐欺っぽかった。車検付き80万円という価格につられて行ったのに乗りだし価格は+40万必要で120万円からになりますとかそんな感じだった。これはアホらしいと思ったのでここでは買わなかった。

ディーラー系の中古車屋はしょぼかった。店はプレハブで車を見に行っても飲み物とか出てこなかった。しかし詐欺っぽいところはなくて、何も言ってないのにカーセンサーに載っけてる値段より安い値段出してきたし、窓にバイザーつけてくださいとか ETC 付けて下さいとか色々言ったら無料でやってくれた。スバル保証みたいのも付いたし、怪しい中古車屋よりネットに出てる値段は高いけど最終的にはディーラーの中古車屋で買うのが良い気がした。

新車とかは一生乗れないと思うので死ぬまでディーラーがやってる中古車屋で車を買って乗り継いでいこうと思います。

[1] pry(2.0.0-p195)> require 'open-uri'
[2] pry(2.0.0-p195)> require 'active_support/core_ext/hash/conversions'
[3] pry(2.0.0-p195)> Hash.from_xml(open('http://www.portalshit.net/index.atom').read)
=> {"feed"=>
  {"xmlns"=>"http://www.w3.org/2005/Atom",
   "id"=>"http://www.portalshit.net/",
   "title"=>"portal shit!",
   "updated"=>"2013-06-18T19:07:44+09:00",
   "link"=>
    [{"type"=>"text/html",
      "rel"=>"alternate",
      "href"=>"http://www.portalshit.net/"},
     {"type"=>"application/atom+xml",
      "ref"=>"self",
      "href"=>"http://www.portalshit.net/index.atom"}],
   "entry"=>
    [{"id"=>"tag:www.portalshit.net,2013-06-18T19:04:33+09:00",
      "title"=>"Alfred で Chrome のブックマークを検索する",
      "published"=>"2013-06-18T19:04:33+09:00",
      "updated"=>"2013-06-18T19:07:44+09:00",
      "link"=>
       {"type"=>"html",
        "rel"=>"alternate",
        "href"=>
         "http://www.portalshit.net/2013/06/18/chrome-bookmark-search-with-alfred"},
      "content"=>
       "<p><img src=\"https://resources.portalshit.net/945-chrome-bookmark-search-with-alfred.png\" alt=\"945-chrome-bookmark-search-with-alfred.png (708×295)\
      "author"=>{"name"=>"morygonzalez"}},

で XML の内容を Hash にできる。ActiveSupport 便利。

みんなやりたいようで検索したらいっぱい出てきた。一番上に出てきたのは中の人が作ってるやつ。

Just a moment...

www.alfredforum.com

ただソース見たら php で作られてた。あまり変なもん入れたくないのでスルーして別のを探したらこういうのを見つけた。

Site not found · GitHub Pages

mdreizin.github.io

これは Python 製らしい。偏見かもだけど Python 製なら大丈夫そうだなと思ってこっちを使ってみることにした。

一応ちゃんと動いている。

フッターのキャッシュとかフラグメントキャッシュはできたので、サイトのなかで一番重いアーカイブページのキャッシュを考えてみることにした。

当初はアーカイブページも、一番重い記事一覧表示部分をフラグメントキャッシュしてみていた。しかしあまり効果がなかった。Sinatra は仕組み上、コントローラーにいろいろ書いてしまいがちになり、アーカイブページのコントローラーが Fat になっていた。そのためフラグメントキャッシュをしたところでコントローラーの重い処理はビューがレンダリングされる前に走ってしまい、キャッシュの意味があまりない状態だった。

Rails だったらアクションキャッシュとかあるけど、先日から Folk して改造を進めている sinatra-cache でできるのはページキャッシュとフラグメントキャッシュだけなため、ページキャッシュをしてみることにした。

ページキャッシュの残念な点は Nginx 側の設定も必要なことだ。せっかく Lokka は Heroku や Sqale など Rack アプリケーション置ける PaaS にならどこにでも置けるのに、Nginx の設定変更を前提とした変更を行うと CMS for Cloud ではなくなってしまう。しかしこのブログは自分の勉強の場でもあるのでえいやっとやてみた。

sinatra-cache は Lokka + Nginx + Unicorn という環境であれば、LOKKA_ROOT/lib/lokka/app.rb を開いて以下のようにしてやれば使えるようになります。

require 'lokka'
require 'sinatra/cache'        # <= 追加

module Lokka
  class App < Sinatra::Base
    configure do
      # ...
      register Sinatra::Cache  # <= 追加
      set :cache_enabled, true # <= 追加
      # ...
    end
    # ...
  end
end

とかやってやれば、勝手に LOKKA_ROOT/public にキャッシュファイルを作るようになります。Nginx 側でキャッシュファイルがあれば Unicorn に proxy せずキャッシュファイルを返すようにすればページキャッシングで爆速になる。sinatra-cache は {$request_filename}.html という名前でキャッシュファイルを作るので Nginx の設定は以下のような感じになる。

server {
    location {
        root /var/wwww/portalshit/public;
        # ...
        if (!-f $request_filename.html) {
            add_header Cache-Control public;
            rewrite (.*) $1.html;
            break;
        }
        # ...
    }
}

ポータルシットはトップページも重いのでトップページもページキャッシュしようかなと思ったけど、ページングとかあるのでいろいろ面倒くさいことになることに気がついた（キャッシュファイルがない状態で Google のクローラーが 35 ページ目とかをクローリングしてたら 35 ページ目の html が index.html としてキャッシュされてトップページに来た人が全員 35 ページ目を見ることになってしまう）のでやめた。

キャッシュ、レスポンスを速くしてくれるけど何でもキャッシュすれば良いわけではないし奥が深い。

Lokka でキャッシュしたいと書いてたけどキャッシュできるようになった。

Lokka でキャッシュしたい - portal shit!

Lokka がすごく遅いEC2 の micro で Lokka を運用してたけど、Unicorn が CPU 100% 近く使う状態が続き、リクエスト送ってレスポンスが返ってくるまでに 30 秒...

www.portalshit.net

結局 sinatra-cache を使った。sinatra-cache、2 年くらいメンテされてなくて全然だめかなと思ってたけどドキュメントが執拗なほど詳しく書かれてて使い方がわかりやすかったので使ってみることにした。フラグメントキャッシュがページごとに共有されなくて非効率的だったところは適当に改造した（morygonzalez/sinatra-cache · GitHub）。

footer 部分だけキャッシュするようにしてるのでトップページのレンダリングはあまり変わってないように感じる。個別記事ページは HTML が返ってくるまで 2, 3 秒かかってたのが 500ms から 600ms くらいになった。割とよいと思う。

いまのところ cache の有効期間みたいのを設定できないのでこれを任意の時間で設定できるようにしたい。しばらく使ってみて問題なさそうだったら Lokka 本体に Pull Request してもよいかも。