大江戸Ruby会議06 トーク資料
![Docker時代の分散RSpec環境の作り方 // Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/0952ac38f188c46a098172663bf72c533c8b053b/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F1b17f3c9e7e445648ced041a13cb2285%2Fslide_0.jpg%3F7701476)
Photo by Flickr: HerryLawford's Photostream DraperはRailsのプレゼンテーション層の役割を担うgemです。 この記事では、Draperを通し、プレゼンテーション層の必要性や使い方を説明します。 動作確認 Ruby 2.2.1 Rails 4.2.0 Draper 1.4.0 目次 0. プレゼンテーション層の必要性 1. Draperのインストール方法 2. Draperの簡単な使い方 3. デコレーターインスタンスの作成 3.1. 単独のオブジェクトのデコレーター 3.2. コレクションの個々のオブジェクトのデコレーター 3.3. コレクション自身のデコレーター 3.4. 関連するオブジェクトのデコレーター 4. デコレータークラスの作成 4.1. デコレーター内でヘルパーメソッドへのアクセス 4.2. デコレーター内でモデルオブジェク
(2022.5.4追記) FactoryGirlはFactoryBotという名前に変更されています(参考)。この記事は昔の名前である「FactoryGirl」を使っています。 はじめに 今年のゴールデンウイークはMinitestとRSpec、FixturesとFactoryGirlについていろいろ研究(?)していました。 具体的にはこんなことをやっていました。 Rails Tutorial 第3版を写経した(第3版ではMinitestとFixturesを使っている) Rails TutorialのテストコードをRSpecとFactoryGirlで書き直した Everyday RailsのテストコードをRSpec + FactoryGirlからMinitest + Fixturesに書き直した The Minitest Cookbookを読んだ 今回のエントリではMinitestとRSpec
はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか? この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模
前回は具体的なWebアプリを例にして簡単なコードレビューをしました。今回からは、テストを使ったリファクタリングについて解説していきます 少し時間が空いてしまいましたが、前回は具体的なWebアプリを例にして簡単なコードレビューをしました。今回からは、そのWebアプリに対してテストを書いてリファクタリングする具体的な方法について解説していきます。 今回はまず、Ruby on Railsで人気のあるテストフレームワークの数々についてご紹介します。 最近のテストフレームワークトレンド Hamlの作者として知られるHampton Catlin氏が行った「Hampton's Third Ruby Survey, 2010」の中に、テストに関するいくつかの興味深い結果があります。好きなテストフレームワークは何ですかという質問に対する答えをグラフにすると以下の通りです。 これを見ると「ビヘイビア駆動開発(
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く