Андрей Сидоров

Если у вас не постоянно изменяемые индексы по много раз в секунду, а так же не таблица из миллиона строк, то массовый апдейт всех индексов выше или ниже нового значения вполне хорошее решение.
То есть если вы хотите вставить элемент и дать ему индекс 5, то перед вставкой вам нужно выполнить запрос

upate table_name set position = position + 1 where position >= 5

При такой схеме при удалении элемента ничего с остальными элементами делать не нужно.

Решение оставлять "зазор между индексами" в 10-100-1000 и т.д., или делать индексы дробными совершенно не приемлимо. Оно не надёжно в долгосрочной перспективе.

И да, если говорить о типовых задачах, то эта задача типовая.
Есть хорошим гем acts_as_list, который делает как раз нужное. Использует он способ, который я описал ваше.

У вас `authorized` это лямбда. Тоесть это функция, которая будет выполняться каждый раз, когда запрос придёт в рельсы.
А вот это `!authorized`, это отрицание от лямбды, оно всегда будет ложью. Это не отрицание результата выполнения лямбды, это отрицание для самого объекта лямбды.

2.3.1 :001 > ->() { false }
 => #<Proc:0x00000001f744e0@(irb):1 (lambda)>
2.3.1 :002 > !(->() { false })
 => false

Проходят оба expect. В feature тестах scenario является синонимом it из обычных тестов.
Если rspec выдал в логи, что тест прошёл, значит выполнилось всё, что в нём написано.
Чтобы убедиться в этом, попробуйте выполнить следующий код

scenario "root page" do
  visit root_path

  puts 'A'
  expect(page).to have_link("Login", href: login_path(locale: I18n.locale))
  puts 'B'
  expect(page).to have_link("Signup", href: signup_path(locale: I18n.locale))
  puts 'C'
end

Отличия есть. В первом случае код внутри класса будет видеть константы из модуля (и имена вложенных классов соответственно), а втором - нет.
Пример:

module A1
  TEST = 'zz'
end

module A1
  class B1
    def foo
      TEST
    end
  end
end

module A2
  TEST = 'zz'
end

class A2::B2
  def foo
    TEST
  end
end

A1::B1.new.foo #> "zz"
A2::B2.new.foo #> NameError: uninitialized constant A2::B2::TEST

let(:confirm_oauth) { double deliver_now: nil }
before do
  allow(ConfirmOauth).to receive(:email_confirmation)
    .and_return confirm_oauth
end
subject! { do_something_that_calls_mailer }

it do
  expect(ConfirmOauth).to have_received(:email_confirmation).with user
  expect(confirm_oauth).to have_received :deliver_now
end

Другой способ - это метод receive_message_chain https://relishapp.com/rspec/rspec-mocks/docs/worki... Он подойдёт, если не нужно проверять с какими параметрами были вызваны промежуточные методы.

В контроллере:
skip_before_action :verify_authenticity_token

либо фильтровать сразу в запросе

Post
  .where.not(id: @posts_hot.map(&:id))
  .where.not(id: Post.where(post_block_id: 2)) # magic number anipattern. лучше заменить на константу
  .where.not(id: Post.joins(:post_asset).where.not(post_asset: { quote: nil }))
  .order(created_at: :desc)
  .limit(15)

либо отфильтровать после запроса в коде

Post
  .includes(:post_asset)
  .where.not(id: @posts_hot.map(&:id))
  .order(created_at: :desc)
  .limit(15)
  .select { |post| post.post_block_id != 2 }
  .select { |post| post.post_asset.try :quote }

Ноду с рельсами сравнивать нельзя вообще. Никоим образом.
Аналог ноды в руби это https://github.com/eventmachine/eventmachine - фреймворк для асинхронной работы с сокетами. Всё, что можно сделать в ноде, можно сделать и в eventmachine.
Ресурсов eventmachine будет съедать побольше ноды. Не на порядки, но в разы. Это минус, критичный лишь в очень редких ситуациях. Плюсом eventmachine будет то, что использоваться будет не яваскрипт, а руби и вся сопутствующая руби инфраструктура - тысячи библиотек(гемов) на все случаи жизни.

Вы не написали, для какой цели вы выбираете фреймворк, но могу предположить, что для какого-то вебпроекта, для 99.99% из которых ни нода, ни eventmachine не подойдут в виду своей асинхронности и низкоуровневости.

Если вам нужен фреймворк для написания веб приложения, то у rails в среде ruby/nodejs конкурентов просто нет. express.js/sinatra и другие мини фреймворки для чего-то серьёзного рассматривать не стоит, хотя если вы любите выдумывать велосипеды и всё делать руками, то можно.