これは何 「Rails Wayに沿って〜」とはReview欄などでよく言われるが、定義が人によってぶれている気がするので俺のRails Wayを示した記事です。 もはや本来のモノとは別物かも知れませんが、俺はこういう観点でRailsをみて、コードを書いているよ、ということを知ってもらう意味でもこの記事を公開することにしました。 前提として、「数人以上のチームでプロダクトを実際に開発して運用する」場合の自分のスタンスを示したものです。(私も仕事では独自DSLは書きませんが自由研究用途なら自分も独自DSLを書いたりします。) それでは、いってみましょう。 Model層 データベースの操作およびビジネスロジックを記述する。 テーブルの属性は原則NOT NULLにするべき。どうしても要件上NULLを許容しなければならない場合のみNULLを許容する。 Controllerからparamsを無思考で渡
https://shuuu-mai.connpass.com/event/173794/
Rails 6.0の複数DBのレビューしてるときに気づいたことなんですけど、たぶんリードレプリカからデータを読むテストをするのたぶん大変だと思われます。 うちの業務のアプリでActive Recordが更新を検知できない方法でデータが更新されるとテストがコケるという問題が以前にあり、これと同じ構造の問題がマスターのコネクションで更新したときマスターのコネクションのクエリキャッシュはクリアされるけどリードレプリカのコネクションのクエリキャッシュは残ったままというのがあるよね、というのをテストコードで示そうと思ったときのことである。 github.com 通常RailsアプリでDBつかったテストをするとき、テストの中で変更されたデータを毎回初期状態に戻すのにフィクスチャーをロードし直すのは時間がかかって効率がわるいので、テストケースに入る前にトランザクションを開始しといてテストケース終わったら
ピクスタ開発部で毎日ヒィヒィ言いながらエンジニアをやっております @muramurasan です。 今回はPIXTAのとあるリポジトリにおいて、未使用のメソッドを削除しようとした際、gemを組み合わせることで、効率的かつ安全に削除することができたという話をしたいと思います。 よくやる方式 外部の勉強会などで、「未使用のメソッドを削除する際にどうしているか?」ということを聞いた際、よく聞くのが「未使用らしきコードを見つけ次第、ロギングを行うメソッド呼び出しを挟み込んでいく」というものでした。 この方式は、動的なメソッド呼び出しにも当然対応できますし、お手軽なので、一般的に好まれているようです。 問題点 ただし、この方式では以下の問題点があると私は考えています。 そもそも、未使用らしいメソッドを見つけるのが大変 プロダクションコードを汚してしまう これらの問題を解決するために、PIXTAでは
昨日のRails Developers Meetupで綺麗なテストコードの書き方について発表してきました。 Rails Developers Meetup #1(東京会場) - connpass 資料はこちら 余談 もともと数年前くらいから、テストコードの書き方についてまとめたいなーと思っていたのですがなかなかキッカケがなくて手を付けられていませんでした。今回のミートアップ駆動で一通り形にするところまでいけて今とてもスッキリした気持ちです 😇 もっと多くの人にテストコードの書き方を意識してもらいたいので、また機会があればどこかで喋りたいですね。 昨日発表した内容はGitHubリポジトリにまとめたものの一部です。綺麗なテストコードの書き方について詳しく知りたい方は下記のリンクからどうぞ。 willnet/rspec-style-guide お願い 今回まとめた内容はあくまで僕が考えるテスト
All slide content and descriptions are owned by their creators.
minne 事業部チーフテクニカルリードの @_shiro16 です。 おかげさまで minne は 1 月 17 日に 5 周年を迎えました。その 1 週間後の 1 月 24 日に Rails4.2 から 5 へのアップグレードを行いました。 そこで今回はアップグレードを行う際に行ったことの一部をご紹介します。 はじめに 今回は基本的なアップグレード手順の説明は省略し、minne ではどのように進めていったかを解説していきます。 アップグレード作業は主にチーフエンジニアの @hsbt と僕の 2 人で進めました。 まず minne がどの程度のコード量なのかをご覧いただこうと思います。 minne の rake stats の結果は以下の通りです。 基本方針 DEPRECATION WARNING は出来るだけ消す 可能なものは積極的に backport 上記のような 2 つの大きな方針
2016 - 09 - 09 Rails だって硬いデータベース設計をしたい!そんなあなたに贈る Tips 4 選 list Tweet こんにちは、ペロリのサーバサイドエンジニアの @a_suenami です。 今回は Ruby on Rails アプリケーションにおけるデータベース設計についてちょっとご紹介したいと思います。 データベース設計してますか? みなさん、データベース(以下、DB)設計していますか?Scaffold したときにできた migration ファイルをそのまま使ったりしてませんよね? Ruby on Rails (以下、 Rails )は CoC(Convention over Configuration: 設定より規約)を強く提唱している フレームワーク であり、それによって得られる恩恵も大きい反面、かなり強めに設計の自由度を束縛されるという特徴もあります。特に
クラウドワークスの弓山 (@akiray03)です。 前回のブログに引き続き、Rails3からRails4にアップグレードした際に行った工夫をご紹介したいと思います。前回の記事を未読の方は、合わせてどうぞ。 engineer.crowdworks.jp 今回は、「モンキーパッチ」に焦点をあてて、取り組みを紹介します。安全な並行稼動を実現するために、いくつかのモンキーパッチを作成しました。作成したモンキーパッチを振り返ってみると、以下のように分類することができます。 Rails3/4並行稼動時に、双方を分離するためのモンキーパッチ Rails3/4並行稼動時に、双方の振る舞いを揃えるためのモンキーパッチ Rails3の振る舞いをRails4と揃えるためのモンキーパッチ (Rails3側にパッチを当てた) Rails4の振る舞いをRails3と揃えるためのモンキーパッチ (Rails4側にパッ
昨日こんな記事が話題になっていました。 ≫ 登録されるとつらいユーザー名リスト - Qiita ああ、ちょうどまさにこういうルーティングのWebサービスを作っているところだったりすので、とても参考になる情報。ということでサクッとRailsのValidatorにしてみました。元記事のコメントに書かれていたものと、自分で思いついたものも追加してあります。ついでに複数形にも対応してます。 これをapp/validators/ban_reserved_validator.rbに配置。 Model側ではこんな感じで定義すれば予約語を禁止できる。 class User < ActiveRecord::Base validates :name, ban_reserved: true end やや力技感がありますが、ユーザー登録時にしか走らない処理なので、こんな感じのハードコーディングでも十分かと。
クラウドワークスのエンジニアの森田(@minamijoyo)です。 ついにRails5がリリースされましたね。今日はRails5じゃないですけど、Rails3/4並行稼働させた話をしようと思います。Railsバージョンアップを検討している方々の参考になれば幸いです。 はじめに 去る2016/03/28 「Rails Upgrade Casual Talks」というイベントでRails3/4並行稼働させる仕組みを作ってる話をしました。 イベントの模様はエンジニアブログにきびたん(@ctokoro_me)がまとめてくれてるのでこちらを参照して下さい。 engineer.crowdworks.jp 上記のイベントで発表した内容はこちらです↓ Railsバージョンアップを段階的に行うためにRails3/4並行稼動させる仕組みを作ってる話 from Masayuki Morita www.slide
いやー、意外と苦労しました。 第一稿は、オブジェクトが初期化出来なかったので破棄し、 第二稿は、初期化に必要な情報が直書きだったので書き直し、 これが第三稿です。 secret = ActiveSupport::CachingKeyGenerator.new Rails.application.key_generator encryptor = ActiveSupport::MessageEncryptor.new secret.generate_key(Rails.application.config.action_dispatch.encrypted_cookie_salt), secret.generate_key(Rails.application.config.action_dispatch.encrypted_signed_cookie_salt), serializer:
(訳注:2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50~100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング(これは全く別の難物で、あなたのアプリケーションに実装する必要はありません)は、別の機会で扱いましょう。 するべきキャッシングをしない理由
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
似ているようで全然違う!?Activerecordにおけるincludesとjoinsの振る舞いまとめRubyRailsActiveRecord Activerecordを使ってるとき、関連(Association)のあるmodel同士をまとめて取得したい時がけっこうある。そんな時、includesやjoinsを使えば効率良くデータを取得出来るんだけど、実はこの二つは振る舞いや特徴が全然違ってたりする。ややこしい気がしたので、ここでちょっとまとめておく。 先に結論を書いておくと、基本的には includesは先読みしてキャッシュしておく。 joinsはただINNER JOINしてくれる。 と思っておけばOK。 ちなみに、railsのversionは4.1.0。Web上に落ちてる情報は古いせいか若干現状の挙動とは違ってたりしたので、気をつけた方が良さそう。
For years there's been numerous hacks and ways to get Ruby on Rails to run on IIS. There's also ways to get Java via Tomcat or Jetty, Go, and other languages and environments to run as well. There's ways to get Node.JS running on IIS using iisnode but that's been node-specific. The blog posts you do find say things like "get Rails to run on IIS in 10 steps" and I'm like JUST TEN?!? Why not 13? Oth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く