portal shit!

技術のことを書いてたブログ（ tech.portalshit.net ）を Amazon S3 で公開するようにした。9月くらいまでは EC2 の micro に置いてたんだけど EC2 micro でも高くて家族の理解を得られなくて terminate したので表示できなくなっていた。

やり方は以下の Qiita の記事を参考にした。jekyll-s3 という gem 入れればよかった。簡単だった。

静的ウェブページはJekyllとAWS-S3が簡単確実 #Webページ - Qiita

Warning: 2014-5-15 このページの情報は古くなっています。jekyll-s3のメンテが中止されて、新しくs3_websiteとなり使い勝手が変わっています。気が向いたらアップデートの記事を書きます。こちらの記事は参考程度としてくださいm(_ _)m Je...

qiita.com

手順ミスって US リージョンで公開することになったけど遅さとか感じないのでこれで良いかなと思う。

Jekyll 、なんか Liquid みたいな特殊なテンプレートエンジンだし、 Lokka の方が Rack アプリケーションの勉強になるし自分でつくった Syntax Highlighter 気に入ってるのでプログラミングっぽいこともここに書くようになってしまった。しかしそのうち気が変わってまたあっちに書き始めるかも知れないのでとりあえず公開できる状態にしておく。ちなみに tech.portalshit.net は最初、今はなき Mephisto という Rails 製のブログツールで構築してて、デザインは Mephisto 用のものを Jekyll に自分で移植して使ってる。

関連してそうな記事

• パソコンの話とかは tech.portalshit.net に書きます

公開している Lokka の DB (MySQL) のデータを、手もとの Lokka の DB (SQLite) に取り込むときに毎回やり方を忘れるので書いておきます。

今回は MySQL to Sqlite converter という gist のコメント欄に書いてある以下の方法を試した。

sudo gem install sequel
sudo gem install sqlite3
sudo gem install mysql
rbenv rehash
sequel mysql://user:password@host/database -C sqlite://db.sqlite

これでデータを MySQL から SQLite に変換できた。Lokka をローカルで起動してアクセスしてみるが記事が表示されない。DB の中にはちゃんとデータが入ってるし、管理画面から記事一覧を表示するとちゃんと記事が表示される。どうも Post.published が [] を返すみたい。

手でクエリを投げてみると

sqlite> select * from entries order by created_at desc limit 1;
             id = 960
        user_id = 1
    category_id = 5
           slug = eye-pro-is-shit
          title = Eye-Fi Pro を買ったけどクソだった
           body = [hitode909さんの日記](http://hitode909.hatenablog.com/entry/2013/05/24/093749 "hitode909の日記")を...
           type = Post
          draft = 0
     created_at = 2013-10-06 07:28:00.000000
     updated_at = 2013-10-06 13:11:23.000000
frozen_tag_list =
         markup = redcarpet

draft = 0 なので表示されそうなもんなんだけど、よくよく調べてみると SQLite には Boolean 型がなくて、DataMapper は SQLite に Boolean 型のデータを保存するときは t/f の文字列で保存するみたい。これは盲点だった。

結局 draft = 0 を draft = 'f' に変えてあげればすべての記事を表示できるようになった。

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

Ruby 関連のことを検索していて Shopify の中の人のブログにたどり着いた。なかなか面白いことが書いてあった。

Why I'm glad my iPhone broke

sirupsen.com

この人は去年の 11 月に iPhone 4 を落として割ってしまったらしい。すぐに iPhone 5 を買おうとしたのだけど、思いとどまって一月ほど iPhone なしで過ごすことにしたそう。自分がどのくらい iPhone に依存してるのか知りたかったのだとか。そしたら意外と良かったらしい。以下超訳。

iPhone があった頃は常に Facebook、Twitter、Email、iMessage、携帯、HipChat、Skype や対面での会話と心が安まらなかった。プッシュ通知を切ったとしても空き時間にメールチェックしたり Twitter や Facebook を見てしまう。常にオンライン状態で、どこにいてもどこにもいないような感じがつらかった。iPhone がなくなったらコンピューターの前にいるとき以外は目の前の友達や同僚のことだけ気にしていればいい。スマートフォンは作業と作業の合間の、さっきまでやっていたことと次にやるべきことについてに省みるべき時間を、ぼーっとゲームをしたり Twitter を見るような用途に費やす手助けをしていることに気がついた。スマートフォンがなくなってからアングリーバードやったり、Facebook を見たりして無為に時間を過ごすことがなくなり、やるべきことに集中できるようになった。

スマートフォンをやめて Nokia レンガ（昔ながらの携帯）で過ごすにあたって、心配してたのが以下の三点だった。

カメラがない

旅行するときはいつも iPhone で写真をとっていたけど、カメラは人に借りれば良いかも知れない。ひょっとするとなくても事足りるのかも知れない。

音楽がない

歩くときは気分を紛らわせるために音楽を聞いていた。しかし本当に音楽を聞きたいときはパソコンの前に座れば良いことに気がついた。音楽なしで歩いてもしんどくないし、周囲の物事に心を巡らせる良い機会になった。

地図がない

iPhone の Map は多用していたけど、方向感覚に自信があったのでどこかに行くときに地図を見るのをやめてみた。そうすると出発前に入念に準備が必要になった。外国に行くときは紙の地図を使った。また本当に迷ったときは人に道を聞けば良いし、尋ね先の人に電話して道を尋ねれば良い。

3ヶ月ほどスマートフォンなしで過ごしてみて、期待していなかった以下のメリットに気がついた。

よく人に電話するようになった

iPhone の頃はメールを多用していてほとんど電話をかけていなかったけど、古い Nokia の携帯だとメールを打つのがつらくてしょっちゅう電話をかけるようになった。同世代の人に電話をかけるとびっくりされる（みんなメールしか使わないから）。携帯の根本機能と会話の楽しさを再発見した。電話した方が話が早く済みそうな場合や深い話の時はメールではなく電話しか使わないようにしている。

携帯の存在を気にしなくなった

鞄の中に適当に携帯を突っ込んで出かけるようになった。ポケットに何も入ってなくて気楽になった。眠る前に携帯がどこにあるか探さなくていいし、安い携帯だからキズが入らないように気を付ける必要もない。心配事が減るのはいいことだ。

上に挙げた懸念事項は正しかったが、それなしでもやっていける

確かに色々不便だがなくてもやっていけることに気がついたし、スマートフォンを持たないことによって得られるメリットがあることもわかった。

“携帯を二週間に一度しか充電しなくて良いのは気が楽” というあたりはなるほどなぁと思った。寝るとき、出かけるときに iPhone を探さなくて良いのも羨ましい。随分楽だと思う。

自分もスマートフォンを使うようになってから Twitter 中毒が重症化し、移動中に本を読むということがまったく出来なくなった。iPad ではなく Kindle がいいと思ったのもネットを見る機能が付いてなくて読書に集中できそうだから。しかし結局手元に iPhone があると Twitter を見てしまう。この人みたいに思い切って落として割ってしまうのが良いのかも知れない。

会社の若者、夏期休暇期間中に徳を高めまくってた。

夏期休暇のまとめ - kitak blog

こんにちは、実家のハウスダストで鼻と喉がやられたきたけーです。 こんなかんじで始まったぼくの夏休み。 昼寝してたら夢にあんちぽさんが現れて「夏季休暇こそ自分を高めようと思わないの？」的なことをおっしゃってた— きたけー（USキーボード買った） (@kitak) 2013, 8月 10 ちょっと早いですけど、夏期休暇中に読んだ本とかやってたことのまとめ。 読みたかった本を読んだり、楽しそうなことリストをいくつか消化して楽しめたかんじ。次の楽しそうなことに繋がったので良かった。 読んだ本 ビジョナリー・カンパニー2 - 飛躍の法則 ビジョナリー・カンパニー 2 - 飛躍の法則作者: ジム・コリンズ…

kitak.hatenablog.jp

自分は徳が高まるようなことは特に何もしてない。コード書いてないしプログラミングの勉強もしてない。すこし .vimrc を触ったくらい。

実家に帰ったほかは、家を買おうとしてるので不動産屋に行ったり住宅メーカーに行ったりしてた。

プログラミングの本、『明解! Ruby』が読みかけになってるので読もうと思ったけど読まなかった。『SQL アンチパターン』も必要に迫られて買ったので夏期休暇で読もうと思ってたけど読めてない。

代わりと言ってはなんだけど歴史の本読み始めた。連休前に以下を買った。

大河ドラマとか見るときに日本史の知識ないと厳しいことがあるので Wikipedia 読むんだけど Wikipedia 読みだすと際限ない感じなるので本を買って歴史を勉強してみようと思っていた。丁度日経プラスワンの特集で紹介されてたので読んでみたくなって手に取った。Amazon でも評価高い。

あと夫婦げんかして家を飛び出して向かった天神のTSUTAYAで以下のような本を買った。

どれも古本なので安かった。『「芸能と差別」の深層』は三国連太郎の話が面白そうだったので買った。『夜這いの民俗学・夜這いの性愛論』を買うとき、レジが女の人じゃないなと良いなと思ったけど女の人になってしまって恥ずかしかった。結果的に痔ろうが再発した。

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

当初はアーカイブページも、一番重い記事一覧表示部分をフラグメントキャッシュしてみていた。しかしあまり効果がなかった。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 がすごく遅い

EC2 の micro で Lokka を運用してたけど、Unicorn が CPU 100% 近く使う状態が続き、リクエスト送ってレスポンスが返ってくるまでに 30 秒近くかかる状態になってて、AWS での運用を諦めざるを得なかった。さくら VPS に戻したところ、CPU 使用率もロードアベレージも落ち着いた。しかしレスポンスは遅くて、HTML が返ってくるまでに 5 秒くらいかかってる。

原因調べた

Newrelic を入れて調べてみた。Application が一番遅い。MySQL も遅いけど気になるレベルではないみたいだった。

• EC2 に Application
• さくら VPS に MySQL

という構成で運用していたのが遅い原因だったかも。App も DB も同じサーバーに置いたら Newrelic 上で Database が遅いと表示されなくなった。つまり Application をどうにかするしかない。

やろうとしてること

Lokka で動いててもそんなに遅くないページもある。komagata さんのブログは遅くない（heroku に置いてあるっぽいので heroku 側でキャッシュとかいろいろやってあるのもあると思う）。自分のブログに関してはテンプレートで最近の過去数ヶ月の月ごとの記事数表示したりタグクラウド出したりしてるところが遅そう。なので重い処理のところをフラグメントキャッシュしたい。

試したこと

sinatra-cache

導入できて動いた。勝手にページキャッシュする。フラグメントキャッシュできるけど、キャッシュのキーが URL のディレクトリベースのため、効率が悪い。

padrino-cache

導入できなかった。Padrino::Routing に依存してるっぽくて素の Sinatra で使いづらい。

落っこちてた gist (Simple fragment caching in sinatra)

これも Sinatra が前提。view から使うフラグメントキャッシュ専用ヘルパーメソッド。なんか Sinatra が内部的に使ってるインスタンス変数を上書きするというやり方みたい そのままでは Lokka で使えず <- ｲﾏｺｺ。

最後のやつが一番導入に近いところまで来てるっぽいけど、断片の部分だけ haml のコードを実行させて結果を取得させる、というところがなかなか難しい。Rails の ActionController::Caching のコードを見て参考にしようとしてみたけどちょっとよく分からなかった。

実は最近、仕事で Ruby 書かないおじさんになってしまったので週末に Ruby のコード見てもすんなり頭に入ってこない。ダメだなぁ。