Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

herokuでCarrierWaveを使う場合に注意すること

RubyのGemであるCarrierWaveを使う場合の注意点です。
by

Hideki Ohkubo

on 4 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of herokuでCarrierWaveを使う場合に注意すること

herokuでCarrierWaveを使う
場合に注意すること 大久保 英樹(Job-Hub) CarrierWaveってなに? Rubyのファイルアップロード用Gem
ファイルアップロードに関するメソッドが充実
サムネイルなども簡単に生成できる
Fogを利用してAWS S3などと連携できる かゆい所に手が届いていて
使いやすい、人気のGem でも、herokuで使った場合にはちょっとしたはまりどころがありました。 中にはちょっと気づきにくい注意点もあったので、今日はみなさんと情報共有できればと思います。 1.保存用ディレクトリは外部ストレージを利用する herokuはファイルの保存領域を持っていないので、AWS S3などのストレージサービスとの連携はほぼ必須です。 Bucketってβアドオンがそのうち利用できるかも? 2.キャッシュディレクトリを ./tmp に変更する CarrierWaveは、ファイルアップロードする際にいったんキャッシュディレクトリに一時保存します。 このキャッシュディレクトリのデフォルトが./public/tmp/uploads/
公開ディレクトリなのでちょっと危ない。 herokuのファイルシステムはLinuxで一般的なext3あたり?なのでクライアントOSよりファイル名の制限がきつい WindowsやMacは255文字。バイトじゃなく。 3.アップロードファイル名を255バイト
以内に制限する ファイル名が長すぎる場合、ヴァリデーションエラーを返す。
255バイトに収まるようにファイル名を勝手に切り詰める 3.アップロードファイル名を255バイト
以内に制限する ※ 後者の実装の参考にしてください。 UTF-8文字列を指定バイトに収まるように短くするhttp://qiita.com/items/b42422b56dfac013c78c どゆこと? 4.ファイルの再アップロードで、CarrierWaveのキャッシュを使用しない CarrierWaveの機能:
ファイルアップロード付きのフォームでヴァリデーションエラーが起こったときに、ユーザにファイルの再アップロードさせる代わりに、キャッシュを利用することができる。 4.ファイルの再アップロードで、CarrierWave のキャッシュを使用しない 機能名とかはないけど、結構ありがたい機能 便利な機能だけど、でもWebDynoを複数動かしている場合、herokuでは使えません。
理由は二つ。 理由2:
herokuのWebDynoは各々独立して動作している。キャッシュディレクトリも共有されていない。 4.ファイルの再アップロードで、CarrierWaveのキャッシュを使用しない 最初にPOSTしたときと、ヴァリデーションエラー後に再POSTしたときとで、リクエストを担当するDynoが違う場合がある。 4.ファイルの再アップロードで、CarrierWaveのキャッシュを使用しない 理由1:
herokuのWebDynoの割り当てはランダムで、どのDynoがリクエストを担当するかは決まっていない。 再POSTしたときのDynoが最初のPOSTのDynoと違う場合、アップロードファイルのキャッシュが存在しない。 4.ファイルの再アップロードで、CarrierWaveのキャッシュを使用しない この機能を使ってしまった場合、↓のような例外がスローされます。100%再現する訳ではないので原因を特定しづらく、厄介です。 NoMethodError: undefined method `to_file' for #<CarrierWave::Storage::Fog::File:0x0000000bda9958>
ActionController::MissingFile: Cannot read file /app/tmp/uploads/20130305-2249-2-1886/upload.png とはいえ、このような制限や注意点を乗り越えてでも使いたくなるとってもいいGemです。
ぜひ使ってみてください。 もっといい使い方とか分かったら、情報交換してくださいね。 みんなもCarrierWaveをつかおう! ご清聴ありがとうございました。 http://qiita.com/items/802da14fa3cf67763ba7 考えられる対策 http://jobhub.jp Ruby開発者募集中!! 255バイトを超えるファイル名のファイルがアップロードされると、例外がスローされます。 4.ファイルの再アップロードで、CarrierWaveのキャッシュを使用しない 2.キャッシュディレクトリを ./tmp に変更する 1.保存用ディレクトリは外部ストレージを利用する 3.アップロードファイル名を255バイト以内に制限する WebDyno一個で回しているテスト環境で検証しても再現しないので、さらに厄介です。 まとめ
Full transcript