結局 Happy Hacking Keyboard を自宅用にも買って、家でも会社でも Happy Hacking Keyboard 使ってる。会社で墨を使って家ではホワイトを使っている。キーの押し心地は何となく高級感のある墨よりもプラスチッキーなホワイトの方がマイルドな感じがして良い。しっとりした感じがする。墨はスカスカ感がある。
ホワイトを気に入って使っていたら、キーを押し込むとき本体左下部分がミシミシときしみ音をたてることに気がついた。1万8千円もするのにひどいなぁと PFU に問い合わせたら交換品を送ってもらえた。
全般的に Happy Hacking Keyboard 素晴らしいと思う。みんな買えば良いと思う。
キーボードのことばかり考えてるとそのうち Kinesis とか欲しくなりそうな気がして怖い。
結局交換品もミシミシ鳴る。これは仕様だと思って諦めるしかなさそう。会社で使ってる墨はしっかりしてるんだけどな。
Ruby 関連のことを検索していて Shopify の中の人のブログにたどり着いた。なかなか面白いことが書いてあった。
この人は去年の 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 を見てしまう。この人みたいに思い切って落として割ってしまうのが良いのかも知れない。
[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 便利。
jQuery Validation で特定のイベントに対してだけバリデーションを無効にする方法が分からなくて困ってた。例えばフォームの中の送信ボタンではなくキャンセルボタンが押されたときにはバリデーションを行わずにフォームを送信したいということがあると思う。
調べていたら以下の記事がひっかかった。
input タグの class に "cancel" を指定すれば validate されないとある。ほかに、ボタンの click イベントとかで
$("form").validate().cancelSubmit = true;と書いてやっても良いみたい。こちらは JavaScript で form を submit() するタイプのやつにも使えて使い勝手良さそう。
jQuery Validation 、便利だけどドキュメントが充実してなくてつらい。あとどれが公式か分からないのもつらい。去年くらいまで jQuery Plugin のサイトにドキュメントあった気がしたんだど今は別のサイトに単独で存在してる。
みんなやりたいようで検索したらいっぱい出てきた。一番上に出てきたのは中の人が作ってるやつ。
ただソース見たら php で作られてた。あまり変なもん入れたくないのでスルーして別のを探したらこういうのを見つけた。
これは 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 でキャッシュしたいと書いてたけどキャッシュできるようになった。
結局 sinatra-cache を使った。sinatra-cache、2 年くらいメンテされてなくて全然だめかなと思ってたけどドキュメントが執拗なほど詳しく書かれてて使い方がわかりやすかったので使ってみることにした。フラグメントキャッシュがページごとに共有されなくて非効率的だったところは適当に改造した（morygonzalez/sinatra-cache · GitHub）。
footer 部分だけキャッシュするようにしてるのでトップページのレンダリングはあまり変わってないように感じる。個別記事ページは HTML が返ってくるまで 2, 3 秒かかってたのが 500ms から 600ms くらいになった。割とよいと思う。
いまのところ cache の有効期間みたいのを設定できないのでこれを任意の時間で設定できるようにしたい。しばらく使ってみて問題なさそうだったら Lokka 本体に Pull Request してもよいかも。
