サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
attracie.hatenablog.com
それgem使わなくてもできるよまとめ gemは便利なのですが闇雲に入れるべきものでもありません。とくに用途が限られていて、わざわざgemを使うまでもないことや使用目的以上にgemが巨大な場合は簡単に自分で代替物を作ったほうがメンテナンスやコントロールが容易な場合もあります。 Devise Deviseのような認証機構はシンプルなものであればこういったsessionにuser_idを格納するだけで十分です。 user.rb class User < AR::Base has_secure_password end session_controller.rb if user.authenticate(params[:password]) sign_in(user) end application_controller.rb def sign_in(user) session[:user_id]
default_scope is evil は浸透してきたが... qiita.com 最近では Railsでdefault_scope使うのはやめよう! という意見が強くなりましたね。 default_scopeは default_scope -> { where(removed: false) } こんなふうに論理削除を実装するときに便利です。 しかし管理画面では論理削除されたものも含めて集計したいなど、細かい欲求が出てくると意外とグローバルにスコープがセットされるのは都合が悪い。しかもdefault_scopeはmodelの初期値をセットしてしまう(これだとremoved = false)とか、解除するためにunscopedを使うとリレーションからのチェーンができない(@user.blogs.unscopedでuserのscopeごと消える)など残念な点も多いです。 しかしながら、エ
こんにちは。tkotです。今回はrailsのgemについて。 オススメのgemについて紹介する記事は頻繁に取り上げられるのですが、その反対に使うと弊害が出てしまうgemや、gemを多用することのデメリットについて解説されているものはなかなか無いように思います。 今回やや古くなったRailsアプリケーションの保守を行った際に感じた問題点について紹介したいと思います。 サンプルとなる実際のGemfile Rails3.2.xx, ruby2.0.0-pxxxで動作するアプリケーションです。これを古いと感じるか新しいと感じるかは人によると思いますが、よくあるRails4アップデート前のGemfile構成ではないでしょうか。 gem 'haml-rails' gem 'enumerize' gem 'devise' gem 'mysql2' gem 'bcrypt-ruby', '~> 3.0.0
ウェブサービスを運用していると設計の変更や記事・ページの削除が頻繁にあります。 例えば今まで:author_name/articles/:idというURLで提供していたページがあったとして、これをシンプルにarticles/:idで提供するとします。 このとき何も考えずにURLを変更すると、もともとのURLに付与されていた検索エンジンからの評価が引き継がれません。 このような設計変更からくるURLの変化は301転送をかけてあげる必要があります。 これをrailsで実現するとこうなります。 get ':author_name/articles/:id' => redirect("/articles/:id") 何も指定しないと301転送になります。 ところで改修によるリダイレクトならともかく、categories/break-fastをcategories/breakfastにするとか、非常
carrierwaveはサンプルを読む限りでは保存形式をjpegとかpngとかに決め打って、versionではリサイズしかしないのが一般的な使い方のようです。 しかしこれだと「ネイティブアプリではwebp形式で配信し、ブラウザにはjpeg形式で配信したい」というようなユースケースに対応できません。 carrierwaveはこういったフォーマットのマルチ化ができないのかと思っていたのですが、コードレベルでちょっと工夫すれば簡単にできました。 class PictureUploader < CarrierWave::Uploader::Base version :limit_500x_jpeg do process convert: 'jpeg' process resize_to_limit: [500, 10000] end version :limit_500x do process c
Railsで非同期処理を行う際にデファクトになりつつあるSidekiqですが、実際の運用ノウハウや少し踏み込んだトラブルシューティングは意外とまだウェブ上にリソースが不足しているという印象があります。そこでいくつか、基本的なことから少し踏み込んだ話まで、いくつか紹介したいと思います。 Sidekiqの導入・運用 Sidekiqの導入にはRedisが必要であるということはよく説明されるのですが、もう少し正確に言うとRedisをデータ保存先としてSidekiqというプロセスがスレッドベースで動きます。したがって正常にSidekiqが動くためには通常のRailsのプロセス(unicornやpassenger)のほかに、redis-serverのプロセス、Sidekiqのプロセスが動き続けていることが必要になります。(厳密に言えばSidekiqだけ動けばいいならRailsプロセスは不要です) re
このページを最初にブックマークしてみませんか?
『attracie.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く