Ruby や Rails の Upgrade Knowledge 情報提供大歓迎。関連しそうなリンクをどんどん追加してください リンク先の内容の要約や、同じ内容の記事のグルーピングとかもやっていこう もちろん各ページに直接情報を書いてもok ≫ Rubyアップグレードガイド ≫ Railsアップグレードガイド
![アップグレード - ruby-jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/d777b269771fcdc3ceef7e29a87190beed3dbf63/height=288;version=1;width=512/https%3A%2F%2Fscrapbox.io%2Fassets%2Fimg%2Fcontent-logo.png)
はじめに Qiita株式会社 Advent Calendar 2021の22日目の担当は、Qiita株式会社CX向上グループの@kyntkです! Ruby 3.1で新たなJITであるYJITがマージされました。3.0の時点ではJITを有効化するとRailsのパフォーマンスが低下するということをなんとなく聞いたことがあったのですが、3.1ではどうなるのかが気になったので色々と調べてみました。 結論 正直恥ずかしながら、まだ私自身きちんと理解できていないので、必ず添付してある発表内容等を確認してください また、間違った情報があるかもしれないので、そこはコメントや編集リクエストでください!!! Ruby 3.0でMJITを有効にすると、デフォルト設定ではRailsアプリケーションではパフォーマンスの低下が起きうる Ruby 3.0.0 Released Ruby 3.1ではパフォーマンスは改善さ
Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった!」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
はじめに 業務で使っているわけではないのですが、個人的にコツコツVue.jsの勉強をしています。 今回は今まで勉強したことを整理する意味合いも兼ねて、チュートリアルのようなものを作成したいと思います。 見ていただいた方の参考になれば嬉しいです。 また、JavaScriptに関しては書き慣れていないので、もしもっと良い書き方などありましたらご意見いただけると幸いです。 なお、テストコードはまだ書けておりません。。。 次回の記事で各コンポーネントのユニットテストを書きたいと思っています。 2017/09/20 追記 試しに書いたテストコードの差分を、記事の最後に追記しました。 作るもの 簡単なTODOアプリです。 (どっかのサービスに似ていると言わないでください。。。) TODOの管理はRailsのAPIで実施します。 前提条件及び環境 Ruby、Rails、Node.jsの環境をご用意くださ
Rails serverを起動する際に、通常は bin/rails s あるいは bundle exec rails s と実行するかと思います。しかし単にログがつらつらと流れるだけなので見にくくないでしょうか? というわけで、見やすくする↓こんなツール(rails-dashboard)を作ってみました。 ↓ レスポンスタイムの内訳を見たり、 ↓ リクエストパラメータを見たり、 ↓ SQLを見たり、 ↓ レンダリング情報を見たり、 ↓ 生ログを見ることができます。 使用方法 1. rails-dashboard はnpmなので、まずはインストールします。 $ npm install -g rails-dashboard # インストールできたかの確認で、バージョンを表示 $ rails-dashboard -V 2. Railsアプリケーションのディレクトリで、 rails-dashboa
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
Rails等で毎日APIを納品している界隈の皆様方は、リクエスト毎にグローバルな変数を持ちたい時はたまにあるかと思います。例えば、ログを吐くためにRack::Requestオブジェクトをロガーから参照したいとか。モデルやサービス層である処理が呼ばれる毎にリクエスト者のAuditログを残したい場合などそうなりそうです。 class PostEditService def initialize(post, request) @post, @request = post, request end def call(new_body) @post.body = some_normalize(new_body) #... Rails.logger.info("[audit] ip: #{@request.ip}, ua: #{@request.user_agent}") end end サンプルのコ
All slide content and descriptions are owned by their creators.
2016 - 05 - 06 Rails アプリケーションにおけるリファクタリングの実践 Ruby on Rails こんにちは、MERY のサーバサイド開発をしている末並 @a_suenami です。 TDD、 アジャイル 、DB 界隈等によく出没しますが、最近では糖質警察としてのほうが広く知られている気がする今日この頃です。糖質制限に興味ある方はぜひウィスキーを片手にケトン体の話でもしながら飲みましょう。 さて、現在、MERY は Ruby on Rails で開発されていますが、最初にリリースされたのはもう 3 年近く前であり、その頃とはサービスを取り巻く状況が大きく変わってきています。これまで多くのユーザの「かわいい」を支え、よい体験を提供し続けてきた現在の MERY とそのコードベースを否定することは決してできませんが、日々変わるユーザの「かわいい」ニーズと我々のビジネス状況の変
タイトルの通り。 ちょっと調べたらDHHのgistが見つかって、割と良さそうだったのでそれをそのまま使用する事にしました。 # config/routes.rb class ActionDispatch::Routing::Mapper def draw(routes_name) instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb"))) end end Rails.application.routes.draw do draw :api end # config/routes/api.rb namespace :api do namespace :v1 do resources :users, only: %i(index show) end end こんな感じ。 一点問題があって、このままだと
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
(訳注:2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50~100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング(これは全く別の難物で、あなたのアプリケーションに実装する必要はありません)は、別の機会で扱いましょう。 するべきキャッシングをしない理由
このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects
はじめに railsのsprocketsがキツイ。特にjsファイルが多くなると開発がとっってもキツイ。 layoutに こうやってるだけでも出力されたhtmlにはscriptタグが30個ぐらいならんでて、ページの読み込みに10sec以上かかる。 だけど、単にapp/assets/javascriptsをgulp watchとかはしたくない。 なぜならビルドはブラウザのリロード時に変更がある場合だけして欲しかった。 あとwindow.AppNamespace以下にモジュール追加していくのも辛い。 モジュール同士の依存関係もよくわかんないし、何よりwindow.AppNamespace.Modules.UserList.ItemViewとか長すぎ! browserify-railsってやつ使ってみた browserifyがrailsの仕組みの中で動くようになる。 browserify-rail
皆様はじめまして、spicelifeエンジニア@yuki3738と申します。 あけましておめでとうございます。本年も弊社サービスのtmixと\SPOTLIGHTS/をよろしくお願い申し上げます。 さて年末のことではありますが、なんとわたくし皆様が大好きなあのフレームワーク、Ruby on Railsにコントリビュートをしました。 今回はエンジニア歴約半年の私がどんなインチキ経緯があってコントリビュートにまで至ったのか、またそれによってどんな学びがあったのかをお話ししたいと思います。 rails dbができない 事の発端は弊社プロダクトの一つであるtmixのdbの中を見ようとrails dbコマンドを叩いたことから始まります。 Railsエンジニアだったら確実にお世話になるであろうこのコマンド、なぜかわたしのtmixのリポジトリでは起動することができませんでした。 rails dbを入力する
Paul Sobocinski Paul has over ten years of full-stack web applications development experience. He has built and scaled apps on LAMP stacks as well as on Ruby on Rails. He currently works at Nulogy as a Software Developer, where he enjoys practicing TDD and pair programming on a daily basis. 1 Introduction In this article, we're going to compare the relative merits of Ruby on Rails and Sinatra by b
技術部の鈴木 (@eagletmt) です。 クックパッドでは8月に本体アプリケーションや API サーバ等で使われている Rails のバージョンを 3.2 から 4.1 へ順次アップグレードを行いました。 アップグレードは主に松田さん (@amatsuda) と私で進めました。 この記事ではアップレードの際に遭遇した問題の一部を紹介します。 MySQL strict mode の有効化 MySQL を使っている場合、Rails 4.0 からデフォルトで @@SESSION.sql_mode = 'STRICT_ALL_TABLES' が最初に実行されるようになりました (Ruby on Rails 4.0 Release Notes) 。 これを無効化するために database.yml で strict: false という設定が用意されています。 しかし、同じく Rails 4.0
速さが足りない!!!!! そんな時はプロファイリングの時間ですね。 Rubyには標準添付ライブラリとして profile というプロファイラがついてくる。でもこのライブラリはあまりに遅すぎて実用に耐えないから、多分誰も使っていない。ほとんどのRubyistは ruby-prof を使っていることだろう。 今回はこの ruby-prof を使って Ruby プログラムのプロファイリングする方法を紹介する。 計測する(ruby-prof) ruby-profはrubygemsで簡単に入る。 $ gem install ruby-profruby-profというコマンドラインツールがインストールされる。これを使うと、プログラムを変更することなく手軽にプロファイリングを行うことができる。ruby-profコマンドのusageは以下のとおり。 ruby_prof 0.9.2 Usage: ruby_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く