今さらRails3メモ - 番外編その1: Paperclip and Dragonfly -

アップロード画像は変遷がいろいろ激しいみたい

画像をアップロードしてそれを表示に利用するのはとてもよくある処理だと思うんだけど、ゼロから実装するのは意外に面倒くさい。でも Rails には便利な plugin があるので大丈夫。

歴史的なことは知らないんだけど、最近は

の二択くらいな感じみたい。どちらも簡単に扱えるけどどっちかというと Dragonfly の方がより簡単で好きかも。ただし今のところ Dragonfly の方が情報は少ないけど。

Paperclip

thoughtbot/paperclip - GitHub

migration

README から抜粋すると以下の field を持つテーブルが必要らしい。らしいっていうか、実際試してみたんだけど、このエントリ書くまで日が空きすぎて忘れてしまった。

class AddAvatarColumnsToUser < ActiveRecord::Migration
  def self.up
    add_column :users, :avatar_file_name,    :string
    add_column :users, :avatar_content_type, :string
    add_column :users, :avatar_file_size,    :integer
    add_column :users, :avatar_updated_at,   :datetime
  end

  def self.down
    remove_column :users, :avatar_file_name
    remove_column :users, :avatar_content_type
    remove_column :users, :avatar_file_size
    remove_column :users, :avatar_updated_at
  end
end

Model

上の migration に対応する Model はこうなる。

class User < ActiveRecord::Base
  has_attached_file :avatar

  ...
end

ここで画像用の attribute は avatar になって、file_name やらなんやらは meta data としていい具合に処理してくれるようになる。

View

こんな感じ。

<%= image_tag @user.avatar.url %>
<%= image_tag @user.avatar.url(:medium) %>
<%= image_tag @user.avatar.url(:thumb) %>

今回の例は User モデルに avatar 関連の attribute をそのまま載せているが、分離して association でも処理できる。

form 側はこんな感じ。

<% form_for :user, @user, :url => user_path,
            :html => { :multipart => true } do |form| %>
  <%= form.file_field :avatar %>
<% end %>

単に file_field に当てはめるだけ。

参考

Dragonfly

http://markevans.github.com/dragonfly/

Paperclip のようにはドキュメントや紹介記事を見かけないけど、コードを覗いていくと storage として file, mongo, s3 が使えるみたい。

下準備

config/initializers/dragonfly.rb

require 'dragonfly/rails/images'

migration

最低限一つだけ field があればよいみたい。

class MyMigration < ActiveRecord::Migration

  def self.up
    add_column :albums, :cover_image_uid, :string
  end

  def self.down
    remove_column :albums, :cover_image_uid
  end

end

Model 上でどんな attribute に画像を紐づけるか決めて、

#{attribute}_uid

があれば ok.

Model

上の migration に対応する最低限の Model の記述は

class Album
  image_accessor :cover_image
end

image_accessor で attribute を指定するだけ。すると以下のような感じで meta data を取れる。

@album.cover_image.width
@album.cover_image.height
@album.cover_image.number_of_colours
@album.cover_image.mime_type

View

<%= image.caption %></th>
<%= image_tag( image.photo.process(:thumb, '240x240#').url,
               {:size => '240x240', :alt => image.caption} ) %>

こんな風に書ける。

form 側は

<% form_for @album, :html => {:multipart => true} do |f| %>
  ...
  <%= f.file_field :cover_image %>
  ...
<% end %>

同じ要領ですな。

注意

当たり前だけど image_tag を生成すること。でないと表示されない。

生存報告

今年に入って日記の更新頻度がガタ落ちしてますが、別にバーンアウトしたわけではないし、Twitter の方に細かい思いつきや文句を吐き出せて満足しているのもあるけどそれだけでもないです。

いちばんの理由はある程度以上の長さの日本語を書く気力すら残らないほどヤラレているからです。

Fastladder はいつも pin 留めが 100 を越えてから本文を読み始める始末だし、ブックマークの方もタグすらつけてないものが多くなってきていよいよ訳が分からなくなりそう。1まぁ本文を読んでないだけでフィードに目を通す時間はまだ確保できてる分マシなのかもしれないけど。年末から Amazon で頼んだけど配送予定が立たず、リアル店舗を探し回ってまでゲットした本が何冊もあるのに全然読めてませんT_T

まだしばらくはこんな感じかなぁ。ま、身体も心も病んでないのが幸い。単に体力がなくて無理が効かないだけとも言う。世の中にゃこれに加えて毎日通勤地獄に耐えている人がゴマンと居るわけだから恐れ入るよね、まったく。

  1. 最近やっと気づいたけど、自分の場合は調べもの以外では読む時間がない方がブックマークは多くなる傾向があるらしい。 ↩

それ実は考えてた。

Web2.0時代のコメント機能の条件

……と、ここまで書いてたんだけど実は今ならはてなブックマークに全部丸投げでもいいかもね。APIで全コメントを取得してページのフッタにべろっと展開して、ブログの画面のコメント入力欄のように見えるフォームは、実はb.hatena.ne.jpにポストするという。

実はコメント欄のない splash star を見て、「ぶくまでも始めるか」と思っていた。でも本家にコメント欄がつくならそれ使おうっと。

でも何に対してコメントつけようと思っていたのかはもう忘れた。

wiki-study

wiki-study

あとで申し込むメソッドを日記でやるテスツ。

GMail アカウントあればどこからでも申し込みできて便利かなぁ。Gmail Invite もついでに please してみるテスツ。

※ 自宅サーバに IMAP ってのは ToDo には入ってるんだけど、そんなに強く必要性を感じないし面倒くさいので進んでません。

PHPOOT

Amrita に inspire された PHP 用のテンプレートエンジン。個人的にはこれが本命だな。しかしサイトが丸ごと phpDocumentor の出力結果ってのがまた豪気だ。

PHPosxom はどうだろう？

DB が要らなくて PHP だけで動くツールって少ないからね。blosxom は書き手が HTML を使えることを前提にしている感じはするけど、それこそ local の Wiki で書いてできあがった HTML を貼り付けちゃえばいいと考えているので、自分および職場の環境として悪くない。なんとなれば PHP で動いている本番サーバでも活用可能なのが PHPosxom なわけだ。おっほっほ。テストテストだぜ。

CTM

from http://slashdot.jp/comments.pl?sid=160835&cid=503611

便利なのか？ デルタってなんだ？ それより cvsup は fw を自由にできない環境では使いにくいものだったのか。知らなかった(^^;

blosxom テスト

いやだいやだと言いながら使い続けている tDiary. まーここの日記はそのまま行くかもしれないけど、説教講座はこれだとちょっと使いにくいかなぁという気がしていた。で、これの代わりに blosxom を試してみようと思い始める。以前も一応チェックだけしていたんだけど、結局何もしなかった blog ツールをいよいよ試してみるぞってことですな。MySQL などの DB をバックエンドに要求する blog ツールが多くなっている中、blosxom は Pure Perl で完結しているところがいい。別に DB 前提でも悪くないんだけど、なんだか大げさな感じするし、ちょこっとデータを直そうと思ったときに Zope みたいな ODB じゃない、伝統的な RDBMS はちょっと扱いにくい。そこまで膨大なデータ量でもないし、パフォーマンス低下よりもバックアップとかを考えるとコストの方がでかいんじゃないかな、DB 前提のものは。

blog って、別に CGI でデータを更新しなくても blog なのね。まぁその方がクライアントサイドでも工夫ができるので、そういう点はいいよな。つーことで下書きを Wiki でやって、できた HTML を上げて blosxom で表示、つースタイルがよさげな気がしている今日この頃。アイディアとしては今職場のサイトで採用している include_html() と同じようなもんなのかもしんないな、もともと blog って。要するに更新部分だけを更新しやすくすることがスタート地点なのであって、trackback だの theme だのなんて後付けじゃねーかと。

About

例によって個人のなんちゃらです