| @Mac/iPhone

youpy さんと negipo さん作の Dropbox を使って私家版 gyazo をやるやつ、便利に使ってたんだけど、Gyazo.app の上に画像ファイルをドロップしてアップロードする機能がなかったので改良した。便利です。

使い方ですが、まずDropbox の Public フォルダ内に gyazo というフォルダを作ります。その後上のファイルをダウンロードしてきて、 /Applications/Gyazo.app/Contents/Resources/script と置き換えてください。ちなみに9行目の

url = 'http://dl.dropbox.com/u/2611378/gyazo/' + File.basename(file)

の ‘2611378’ という数字は僕の Dropbox のユーザー ID なんで、ここはご自分のものに置き換えてください。

Dropbox のユーザー ID は普通に使ってる分には分からないので、以下の手順で調べてください。Dropbox の Public フォルダで適当なファイルを選んで右クリックすると Dropbox メニューがでるので、そこから「パブリックリンクのコピー」を選びます。するとクリップボードに Dropbox のユーザー ID を含んだ URL がコピーされるのでそこから取得してください。

22f55e1caf9da3fef24c352bb6eb2a21.png (713×156)

まだ Dropbox のアカウントを持ってない方は以下のリンクから作ってもらえると幸福が実現します。

| @散財

iPad 買った

会社のタブレット端末購入支援制度を利用して iPad 買いました。この場を借りてお礼申し上げます。ありがとうございます。

iPad には否定的だった

iPad、ずっと年寄りとか情報弱者向けのデバイスだと思って無視してた。小金持ちの情弱サラリーマンとか100万以上カメラにつぎ込んでるカメラじじいが飛びついてる印象しかなかった。とにかく入力がしにくそうで、能動的に情報を取りに行くのではなく、受動的にコンテンツを消費することしかできないような印象があった(文字の入力がしにくいと、情報を検索する頻度が落ちそうだから)。そういうのは新聞や雑誌を読む行為とあまり変わらない。余談だけど新聞社などのオールドメディアが iPad 好きなのと関係ありそう。自分たちが思ったとおりにコンテンツを消費させたいという意志を感じる。

なぜ iPad を買ったのか

技術書を電子書籍で読みたかった

最近、技術書を PDF とか ePub とかで読む行為に興味が出てきて(クソ重い技術書持ち運ぶのに疲れた…)、何冊か PDF 版を買ってみて iPhone で読んでみたら耐えられないくらい読みづらくて何らかのタブレット端末が欲しくなり、 iPad を買ってみたくなった。

デジカメで撮ったばかりの写真を見るのによさそう

あと正月とかにカメラで撮った写真をその場で MacBook に入れて見せると親戚一同が喜ぶので、こういう用途にも向いてるかと思った。Retina ディスプレイだし。

買ってどうだったか

読む端末としては優れている

文章を読む端末としては優れている。Reeder for iPad 入れたら読むのがだるくてたまってたフィードを結構消化できた。(Reeder、Mac 版も iPhone 版も iPad 版も買ってしまった。おすすめです。)

Reeder for iPad

また iPhone では無理だった Twitter に貼られている gist (ソースコードの断片)を見ることが出来て便利だった。iPhone では「後で読む」ものを iPad ではその場で読めるのがいい。

写真きれい

Flickr 見るのが楽しい。写真ブログのフィード、かなり未読がたまってたけど、寝っ転がりながら写真を眺めるのが楽しい。寝床に居ながらにして Flickr にアクセスして友達が撮った写真を眺めて回るのもこれまでにない体験だった。

書きにくい

タッチパネルのフルキーボードだるい。フリック入力したい* フリック入力できるそうです。風呂蓋も買ったので斜めに角度つけられるけど、それでも上からのぞき込むようにして文字を入力するのがだるい。

でも革製の風呂蓋はかっこいいのでおすすめです。

iPad Smart Cover(スマートカバー) (Red Cover(革製))

家庭内での共用が難しい

App Store やフォトストリームなど iCloud 系の機能のせいで Apple ID に紐づけられるし、Twitter や Google のサービスを使う際にもログインが必要なのでやっぱり一人一台の方が使いやすい。家族で共用するのは難しいと思う。

総括

Retina ディスプレイやばい

bfd6d1fb52d6bab76b05d8f6ba6aa777.png (675×343)

タッチパネルで高精細なのが良い。タッチパネルのタブレットはキーボード操作のパソコンよりも目とディスプレイの距離が近くなるので、Retina ディスプレイとの相性が良いのだと思う(図参照)。「読みたい!」「見たい!」という気持ちにさせられる。正直 iPad 使った後に MacBook 開くと文字がぎざぎざに見えて正視に耐えない。Retina ディスプレイやばい。

持って台所に行けるし寝床に持ち込める

コーヒーいれながら iPhone でなんか読むのが好きなんだけど、これノートパソコンでは絶対できない。両手ふさがるから。iPad だったらぎりぎり片手で持てるので、コーヒーいれながらなんか読むということができる。

あと枕元に気軽に持ち込めるのがよい。ノートパソコンは排気口から埃が入り込みやしないかと心配になってあまり寝るとき使う気にはなれないけど、iPad は気兼ねなく寝床に持ち込める。何か読んでて眠りついたときに枕の横にあっても邪魔にならない。

気軽に持ち運べる点がノートパソコンとの決定的な違いだと思います。

これから望むこと

iPad、おおむね気に入ったけどもっとたくさん日本語の本を読めるようになったらうれしい。文庫本とかを自炊なしで iPad で読めるようになったら最高だと思う。岩波文庫の80年くらい前に出版されたやつをリストカット感覚で買って読んだりしたい(カラマーゾフの兄弟も iPad でなら読めるような気がする)。

あと Retina ディスプレイの破壊力やばいので次の MacBook Pro は Retina で出して欲しいです。

追記

調べたところ、iOS 5 からフリック入力できるらしいです。「iPad は情報弱者向けのデバイス」とのたまってる僕こそ情報弱者でした。お詫びして訂正します。

| @技術/プログラミング

Homebrew で rbenv と ruby-build をインストールし、Ruby をインストールしている。Nokogiri をインストールしようとするとlibiconv が足りないとエラーがでる。Nokogiri のインストールマニュアルを見ると以下のようなことが書いてある。

homebrew 0.8 or later

brew install libxml2 libxslt
brew link libxml2 libxslt
gem install nokogiri

言われたとおりにシンボリックリンク張って、さらに libiconv にもシンボリックリンクはった。この状態だとちゃんと Nokogiri 入る。入るが、

$ brew doctor

| @技術/プログラミング

7644ee081ba12f35fff2ea939a122da8.png (541×174)

Lokka になくて不便だと感じていたのがスパムコメントの一括削除機能だった。スパムを取得するメソッド、またそれらをまとめて削除するメソッドはあったので、それを呼び出すインターフェースを作ってみた。最初はテストなしで pull request しようとしてたけど Lokka に怒濤のようにテストコードを書いて push している tomykaira さんのブログ記事(lokka コミッタからのお願いをお読みください - tomykaira makes love with codes)を読んで心を入れ替え、本日の Lokkathon でテストコードを書いて pull request してみた。無事 merge して頂きました。

P_BLOG の改造とかして地道にコードを公開したりはしてたけど、やっとオープンソースにコミットできた感じがする。もっと頑張っていきたいです。

| @技術/プログラミング

Unicorn の設定をミスって(たと思ってけど実はそうじゃなかった)ポータルシットが12月の半ば頃から死んだままになってた。きっかけは Capistrano の導入で、仕事で Capistrano 使っていて大変便利なので、これをポータルシットでも使おうとした。

Unicorn で便利なのが、 kill -USR2 `cat tmp/pids/unicorn.pid` とかやることで、ダウンタイム無しに Rails アプリケーションを再起動できるとこだ。これを Sinatra 製の Lokka でも実現したかった。Capistrano と併せて運用することで、サーバーに SSH で接続せずとも

$ bundle exec cap deploy:restart

とかで Lokka を再起動できるようになる。

これまで Lokka の database.yml に DB への接続情報をべた書きしていたのをやめ、起動時にはシェルで以下のコマンドを実行するようにした。

$ env DATABASE_URL=path/to/db bundle exec unicorn -c config/unicorn.rb -D -E production

Capistrano の deploy.rb に書くと以下のようになる。

namespace :deploy do
  task :start do
    run "cd #{current_path}; env DATABASE_URL=#{db_path} bundle exec unicorn -c config/unicorn.rb -D -E production"
  end
end

| @技術/プログラミング

Railsで画面を作っていて、DBを参照せずにselect -> option なHTML(ドロップダウンリスト)を出力したいと思った。DBに入ってない値をドロップダウンリストとして表示する方法。ググったらこういうやり方がヒットした。

このやりが方がかっちょいいのかバッドノウハウなのか判別つかないけど、モデルに定数を書いてそこにいろいろ入れてしまうらしい。以下のような感じ。

class Event < ActiveRecord::Base
  DAYS = ['Monday', 'Tuesday', 'Wednesday', ...]
end

でこれをモデルから参照するときは以下のようにする。

<%= select(:event, :day, Event::DAYS) %>

これでうまいことドロップダウンリストを表示できる。

ところが一点問題があって、このドロップダウンリストで表示したい値が "(ダブルクオーテーション)を含んでいたとする。ダブルクオーテーションはRailsによって自動的にエスケープ処理されてしまうので、 " と表示させたいのに &quot; とか表示されてしまう。Form系のヘルパーメソッドで text_area_tag なら :escape => false とか出来るんだけど、select でそれをやるのは不可能だった。

Railsで文字列のエスケープをせずに出力する方法は一般的に

<%= raw("文字列") %>

とか

<%= "文字列".html_safe %>

だけど、「まさかそれをモデルの中でやっちゃってもエラー出るよね?」と思いながらやってみたらちゃんとエスケープせずにHTMLを出力できた。

モデルクラスのなかにヘルパーメソッドを書くのは気持ち悪いと思うけど、それ以外ではビューの中でイテレータを書いて一個一個エスケープしない処理を書くか、独自のヘルパーメソッドを書くしかない。なんかまどろっこしい気がするのでとりあえずこのやり方で行ってみることにします。

| @技術/プログラミング

Git flow を導入して仕事してる。master ブランチと develop ブランチをベースに、 feature ブランチ、hotfix ブランチ、release ブランチをつくって色々やるあれ。確かに便利何だけどだるいところもある。

hotfix ブランチのバージョン番号

たとえば誰か(A さんとしよう)がバグを見つけて hotfix を start したとする。hotfix 用のタグを 1.0.1 としよう。

$ git flow hotfix start 1.0.1

ここで別の誰か(B さんとしよう)が他のバグを見つけたとする。このとき B さんは A さんがローカル環境で 1.0.1 のタグを既に使っていることを知らない。ので当然 $ git flow hotfix start 1.0.1 してしまう。そんで B さんが