Rails 6 では Action Text と呼ばれるライブラリが使えるようになるとの発表がありました。どんなライブラリかというと、リッチなテキストエリアを簡単に実装できるライブラリです。こういうやつ。 edge rails を使えば手元でも試すことができるようなので、試してみました。まだ α プレビューなので破壊的な仕様変更があるかもしれませんが、練習として。 rails new GitHub から rails/rails を clone してきた状態で試すのが確実なようです。 $ ./rails/railties/exe/rails new blog --edge 走らせると rails 関連ファイルの生成に続いて webpacker のセットアップが行われ、 yarn コマンド経由で JS ライブラリもインストールされます。 Action Text のインストール 2018-10-
こんにちは。技術部の吉川です。 クックパッドでは、ユーザーが快適にサービスを利用できるように本番環境でのパフォーマンスを向上させるための様々な工夫がなされています。 ところでパフォーマンスを気にするのは本番環境だけで良いのでしょうか？ 開発環境に目を向けると、そこにもユーザーがいます。開発者です。開発環境のパフォーマンスが向上することで、開発者が快適にサービスを開発できるようになります。 今回はそういった開発環境でのパフォーマンス向上のための取り組みについてご紹介します。 ※ なお先日 Ruby2.2化されました が、今回紹介するものはそれ以前に実施されたため、Ruby2.2で同じ結果になるとは限りません。 状況 今回対象とするのはcookpad.comのアプリケーションです。 近年はMicroservices化を進めていますが、それでも本体のレシピサービスのアプリケーションは依然として非
追記 コードの全体像がわかりにくいって意見をもらったのでgithubにコードおきました。 (りーどみーがわかりにくいとかあればPRいただけると幸せです) https://github.com/togana/sample-rails-docker versionとか少し変わってたりDockerfileの中で実行してるコマンドが少し変わったりしてますが、大きく変わっているところはないので参考にしてください！ 追記2 docker-machineの共有ファイルを利用している場合、Rails5からファイル変更しても検知できなくなっていました。 ファイルの変更を検知しているのは config.file_watcher という設定です。 ここがバージョンアップに伴い変更されていました。 ActiveSupport::FileUpdateChecker から ActiveSupport::Evented
Dockerで快適なRails開発環境を手に入れるためにやった6つのこと はじめに この記事はDockerその2アドベントカレンダーの14日目です。 DockerでRails開発環境を作るに当たってしたことについて書きます。 普通のRails環境構築については他に記事がいっぱいあるのでそちらを見てください。 なお、現在RailsでAPIサーバを書いているのでフロントエンドでのみ必要になることについては触れません。 また、今回の記事を書くにあたってリポジトリをgithubで公開しています。 https://github.com/yuemori/docker-adventcalendar-example アジェンダ Dockerfileとdocker-composeを環境毎に分ける data volume containerを使ってデータをキャッシュする entrykit, dockerize
こんにちは。SmartHR のエンジニアの @meganemura です。 SmartHR はひとつの Rails アプリのリポジトリで開発が進められており、GitHub への Pull Request 作成などを契機に CircleCI でテストの実行や静的解析によるコード品質のチェックを継続的に実施しています。 しかし、プロダクトの成長と共に CI の実行時間が増え、またエンジニアの増加につれ CI のキュー待ちの時間も増え、実行完了までの時間が日々増え続けています。 その状況に対して、 Buildkite という CI サービスを利用して CI 環境の速度を改善した取り組みについて紹介します。 背景 以前にこのテックブログの CircleCI 2.0 の利用 の記事を公開した時点で全体のテスト実行が 40 分弱程度になっていたのですが、現在 50 分弱から 60 分程度にまで増加して
はじめに 先日、RSpec 3.7がリリースされました。 参考: RSpec 3.7 has been released! 上記ブログの中で「今回のリリースはRailsのSystem Testの統合機能をいち早く使ってもらうためのリリースだ」と書いてあります。 実際、ブログの中で触れられている新機能は「System Spec」機能の追加だけです。 というわけで、この記事はrspec-rails 3.7で導入されたSystem Specの紹介と使い方の説明をしていきます。 実行環境 この記事は以下のバージョンを対象にして書かれています。 rspec-rails 3.7.1 Rails 5.1.4 Ruby 2.4.2 selenium-webdriver 3.6.0 Capybara 2.15.4 Chrome 62 ChromeDriver 2.33 サンプルコード この記事で使用したコー
bulletとは、N+1問題や使われていないEager Loadingを発見するためのツールです。 これらの問題があると無駄なSQLクエリが実行されるので、パフォーマンスを落としてしまいます。 気をつけていてもN+1問題は発生してしまう可能性があるので、bulletを導入して自動で発見できるようにしてみます。 ※ N+1問題やEager Loadingについてよくわからない方は、N+1問題 / Eager Loading とはを参照ください。 確認環境 Ruby 2.1.2 Rails 4.1 bullet 4.14.0 目次 Railsプロジェクトの作成 Bulletのインストール方法 Bulletのホワイトリストの設定 Bulletをテストで実行 1. Railsプロジェクトの作成まずはRailsプロジェクトを作成します。 rails new bullet_test cd bullet
Mongoid は、データベースのドキュメントの問い合わせに、2種類のスタイルをサポートします。最初のスタイルは、ActiveRecord風の、ファインダー／動的なファインダーの構文です。2つ目のスタイルは、Mongoid の Criteria API を使った推奨メソッドです。（訳注： 2つ目は Rails 3 の Arel 風です。） ファインダー ファインダーはドキュメントのクラスメソッドです。データベースのオブジェクトを探索するのに、条件のハッシュか文字列を受け付けます。Document.all、Document.count、Document.find、Document.first、Document.last、Document.paginate があります。これらに加えて、アトリビュートが一致しない場合に、作成・初期化する、ファインダー兼作成構文があります。 与えられた条件に合う全
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第2回です。 今回はRSpecのマッチャについて説明していきます。 第1回と同様、今回も「最低限これだけは」という内容に絞り込んで説明します。 使用頻度の少ないマイナーなマッチャ（注：僕基準）については説明しません。 具体的な項目は以下の通りです。 マッチャとは何か to / not_to / to_not eq be be_xxx be_truthy / be_falsey change + from / to / by 配列 + include raise_error be_within + of これからRSpecを始める人はもちろん、何度かRSpecに触れて「うーん、RSpecってわけわからん」となっている人もこの記事で再入門してみると
問題 RSpec で配列の検証をするのに以下のようなコードを書いた。 describe '#payments' do let(:account) { create(:account) } let!(:payments) { [ create(:payment_foo, account: account), create(:payment_bar, account: account), create(:payment_baz, account: account) ] } it 'アカウントに設定された決済方法を返す' do expect(account.payments).to include(payments[0], payments[1], payments[2]) end end このテストコードは正しく動作するが、もっとよく書ける。 includeを使っていると「これらの要素を含んで
はじめに RSpec 3が正式リリースされて2ヶ月ほど経過しました。(正式リリースは2014年6月) ネットの情報を見ていると、これまでは「既存のテストケースをRSpec 3にアップグレードさせる方法」や「RSpec 3で削除されたり、記法が変わったりした点」など、「守りの姿勢」に入った情報が多かったように思います。(僕自身もそういう情報をたくさんアップしていました) しかし、RSpec 3では以前のバージョンでは使えなかった新しい機能も数多く導入されています。 そこで本記事では「攻めの姿勢」で「RSpec 3から導入された新機能」をまとめてみました。 なお、ここでフォーカスするのはテストコードの書き方にダイレクトに関わってくるマッチャの新機能です。 2015.01.12：RSpec 3.1に関する情報を追記しました RSpec 3.1に関する情報も追記しました。 もともと紹介していた新機
Sidekiq とは Sidekiq とは Rails アプリで非同期処理を行うためのライブラリです。複数のジョブを同時に実行することができ、メモリを節約することができます。 ということで今回は Sidekiq の基本と使いかたをざっくりと学んでいきたいと思います。 Sidekiq を使ってみる インストール まず前提条件として Redis が必要なのでインストールしましょう。Redis はジョブの管理に使われています。 brew install redis インストールは Gemfile に追加して bundle install するだけです！ vim Gemfile # gem 'sidekiq' を追加 bundle install Worker を実装する 非同期処理を行うクラスは Sidekiq::Worker を include してつくります。あとは perform メソッド
![[Ruby on Rails] Sidekiq で非同期処理を実装する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9362c0cc4eeac62a6e10ca5d40774aa9e0e0296d/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F03%2Fcatch2.png)
module Api class MaterialsController < BaseController def index render json: handler.find_all end def show render json: handler.find_one(params[:id]) end # ... def update render json: handler.update(params[:id], params[:material] || {}) end private def handler MaterialHandler.new(current_user) end end end 一見すると、「このコード薄いけど何か意味があるの？」「やり過ぎだろ」と思うかもしれない。 しかしこれが私の悩んだ末の結論であり、現在のプロジェクトで実際に動いてるコードである。 解説 先
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
MMMの前田です。 早いもので、MMMに入社してから1年が経過しました。 振り返ってみると、この1年はほぼRuby on RailsでWeb APIを作っていました。 常にRailsに触れることが出来、非常に楽しい一年になりました。 本日はRuby on Rails の Web APIで、クライアントからのパラメータをどのようにチェックしてバリデーションをしているかを纏めてみました。 ruby version 2.2.2 Ruby on Rails version 4.2.2 何故WebAPIのリクエストパラメータのバリデーションが必要なのか 例えばバリデーション無しでパラメータを受け取った場合、以下のコードでパラメータによって期待しない結果になったりします。 Book.where(id: params[:book_id]) 上記のコードはActiveRecordの基本的な検索パターンです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
