Sebastian Skalacki's Profile

Assuming this is form for editing users, is there any good reason why I can't do what's below?

def self.model_name
  User.model_name #instead of ActiveModel::Name.new(self, nil, "User")
end

I use the less hacky approach to use production dump in performance tests. I simply introduce benchmark environment. I just:

1. put require_relative 'test' into /config/environments/benchmark.rb so that benchmark environment mimics test
2. add proper entry to /config/database.yml
3. possibly add Bundler.require(*Rails.groups(:test => %w[test benchmark])) to /config/application.rb to get gems loaded
4. begin my performance_test_helper.rb with ENV["RAILS_ENV"] = "benchmark" ; require_relative '../../config/environment'.

I use RSpec for general testing, so this perfectly works for me. You may need further tweaks (esp. in point 4) if you want to use Test::Unit for other tests too.

Ryan, there is one hidden bug in this episode.

Is:

Redcarpet::Markdown.new(renderer, options).render(template.source).inspect

Should be:

Redcarpet::Markdown.new(renderer, options).render(template.source).inspect.html_safe

You won't see any difference unless you try writing partials in Markdown. I'm on Rails 3.2.12.

How unfortunate that ActiveModelSerializers are nothing more than views without templates. If they were coupled with deserializers, that would be a real difference. Recently I'm trying Roar which is basically the same thing, but works in both directions.

Yeah, I agree. It's a great introductory topic. But there are lots of things to cover.

• differences between .gitignore, .git/info/exclude, $HOME/.gitignore
• useful but not that obvious Git commands (blame, bisect, rebase)
• git submodules (or maybe it's to Gittish?)
• example of good workflow, of course that only true workflow, with rebases instead of "merge master into …" :P
• text editor integrations

So either a good topic for a long episode or a series of two. Or maybe I've written too many git-specific things?

One thing not mentioned in the episode is that HTTP reserves the 409 status code to indicate conflicts. render status: :conflict also works. Set it for your response, especially in APIs.

Metrical is not maintained anymore, see this commit. According to Readme, it may still work when installed with Bundler and run with bundle exec. Revived MetricFu works like a charm, however I had to add it to Gemfile gem 'metric_fu', group: :metrics, require: false and run with bundle exec too. ruby_parser could not be found otherwise.

Currently handlebars_assets supports haml (as well as slim). See readme for details.

Episode 404 is missing, great joke!

Actually when you play with such DBs there is no need for STI cause there are no tables. And class inheritance becomes really good and natural approach then.

Thanks for clearing it! I didn't notice that matchers behavior differs from query methods behavior.

Ryan, I am suprised those tests passed. You should use should have_no_content instead of should_not have_content, see Capybara README. Maybe PhantomJS makes all AJAX synchronous? I don't know. Thanks for tons of great episodes!

What I like in this gem is ActionController::API which is a bit lighter than ActionController::Base.

What I don't like in this gem is everything else.

If you want to create an API application with some HTML admin panel, you either need to use "normal" Rails and rely on ActionController::Base, possibly stripping it somehow, or use "rails-api", but reenable nearly everything. Both approaches suck. Too bad spastorino haven't decided to include ActionController::API in Rails (or maybe that was impossible) and make "rails-api" nothing more than configuration generator.

I prefer to use Grape mounted in routes, so I get nice DSL behind decent Rails middleware.

@50 - sorry, my mistake. It is set by default to hide this param.

You'll have *unencrypted* passwords in your logs! One more thing needs to be done, described here: http://asciicasts.com/episodes/224-controllers-in-rails-3