ActsAsParanoid+CarrierWave使用時で論理削除した際に画像ファイルを消さないようにする - chulip.org
ActsAsParanoidを使用してdestoryをコールするとレコードを論理削除してくれるのですが、 CarrierWaveで指定しているafter_destoryのコールバックが実行されてしまい画像が消えてしまいます。 今回は、論理削除する際に画像を残したかったので調べました。 githubのissuesに同じような場面についての対応が記載されていたのでこれでOKでした。 https://github.com/carrierwaveuploader/carrierwave/issues/624 ORMはActiveRecordを使っているので下記の部分でコールバックが記述されています。 carrierwave-0.6.2/lib/carrierwave/orm/activerecord.rb 27 after_save :"store_#{column}!" 28 before_sa
続・Gitリポジトリ運用の最適解 - chulip.org
このエントリは過去に書いたエントリの続編として位置づけています。 過去の記事：Gitリポジトリ運用の最適解 - chulip.org この記事を書いた当時、いや少なくとも少し前までは本気でマージコミットがないGit運用が最高だと考えていました。 だからこそ、何故A successful Git branching modelがNon-Fast-Forwordマージを推奨しているか疑問であり、昨今のgit-mergeには--no--ffオプションを設定。むしろgit-configでデフォルトの挙動を--no-ffにできるから設定しとけお前らという話に対してよく理解ができていませんでした。 マージコミットがないGit運用が最高だというのは限られた場合の話ではないか ある特定の場合においてのみこの話は適応されるのではないかということに気づきはじめたような気がします。 これは例えばリリース前の開発
Gitリポジトリ運用の最適解 - chulip.org
続編のような物(2012/11/21追加) 掲題の件について最近調べたことをまとめることにします。 はじめに タイトルだいぶ誇張していますが、結論から言うとマージコミットを発生させないGitの使い方です。 マージコミットが悪という言葉を最近よく目にしていたのですが下記リンク先の説明でしっくり来ました。 マージコミットの分割が１本線の履歴の分割よりも困難となる理由 そのためマージコミットが発生しないような使い方を目指します。 また、A successful Git branching modelを実現するためのgit-flowというもののありますが今回は触れません。 (ちなみにA successful Git branching modelではマージコミットは必ず残すことを推奨しています) Non-Fast-Forwordマージでの利点はブランチでの作業履歴が残ることと認識しています。 Fa
Ruby empty?とblank?の違い - chulip.org
empty?とblank?は使う機会が多いのですがなにが違うのか .empty? 文字の長さが0のときtrue .blank? 文字の長さが0かnilのときtrue .empty?の場合nilだったときは普通にエラーがでます You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.empty?後empty?はRuby、blank?はRailsのメソッドであるためRubyの参考書にblank?はなかったりします 最後についている?は真偽値を返すメソッドです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
