Viktor Vsk

В простом случае можно обойтись просто рендерингом xml: railscasts.com/episodes/362-exporting-csv-and-exce...

Для более сложных (цвета, форматирование, графики, объединение ячеек...), кроме axlsx есть другие решения:
https://github.com/woahdae/simple_xlsx_reader
https://github.com/harvesthq/simple_xlsx_writer
https://github.com/roo-rb/roo

simple_reader\writer работают, кажется, только с xlsx (без xls), но, кажется, порядком быстрее.
Roo - просто альтернатива, по большому счету.

Вообще, рендеринг для майкрософт экселя - задача иногда веселая, поэтому у одного гема что-то получается лучше, что-то хуже: бывают выбирают то один, то другой.

Плюс, не забудьте, что если товаров много - может захотеться по расписанию создавать файл, что бы не ждать полную выгрузку при каждом обращении. Или, как вариант, хотя бы кешировать его.

Краткий ответ: что б вы не сделали, это все является html-шаблонами. Потому что в итоге все рендерится в html. Натягивать его куда-то сразу или нет, завист от поставленной задачи, целей и ресурсов. Например, если вы хотите сделать шаблон и выставить его на Envato, то нет ровно никакого смысла верстать его именно под друпал.

Длиииииииинный ответ:
Вам, прежде чем задавать такими глобальными философскими вопросами, сначала надо получше структурировать осознание тех самых процессов разработки.
И для начала, например, отделять идеальное от реального.

Как происходит в реальном мире?
У человека есть идея
С ней он идет к бизнес-аналитику. Тот, в свою очередь, указывает на базовые ошибки, недочеты, формирует какую-то общую картину продукта
Потом он знакомит человека-заказчика с архитектором. На своем языке аналитик объясняет архитектору задачу. Архитектор решает, какой стек технологий лучше всего применить в данном случае.
Далее архитектор идет к проектному менеджеру и ставить уже конкретные задачи.
Менеджер распределяет и доводит задачи до разработчиков и идет на поиски дизайнеров и юзабилистов, которые решают, зачастую уже с заказчиком, как будет выглядеть интерфейс.
После чего результат работы дизайнеров и юзабилистов передается верстальщикам, что бы он мог воплотить их реализацию в машинное представление.
После этого верстальщик отдает html в руки front-end разработчика, который в простейшем случае подключает плагины jquery, в сложном - делает SPA.
Ну, а дальше, по крайней мере сегодня, завист от того, толтый клиент или тонкий. Если сделана SPA, то господа backend'erы могут ограничиться документацией API. А если рендер идет в основном на сервере - то будут "натягивать" результат работы фронтендера на свой движок.
А после этого в игру может вступить (а может и раньше, для поднятия тестового\стейджинг окружения) - администратор для деплоя на серверы. Или даже группа оных, модно именуемых сегодня - DevOps

К чему так много писанины? К тому, что б понять, как примерно выглядит идеальный процесс. Конечно, все описано очень абстрактно, какие-то з венья могут дублироваться, могут дробиться на более узкоспециализирвоанные и т.д., но в общем случае часто выглядеть должно как-то так. Хорошо о процессе расписано у Ф. Брукса (например, Мифический человекомесяц).

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

Мораль: спрашивается, если это все может сделать 1 человек, то зачем городить целый хор разных чуваков, называть их модными словечками и настолько сильно обкрадывать карман заказчика?
Все дело в том, какие цели и ресурсы. И когда за "серьезность" решения хочется заплатить - вначале, или уже в хайлоад-продакшене (уже много модных словечек употребили).
И на самом деле, на перспективных проектах, получается так, что цена ошибки с каждой "роли" по нисходящей - увеличивается. Например, если вы выловили ошибку на уровне общения с бизнес-аналитиком - это дешевле, чем выловить ее в процессе продумывания архитектором решения. А поймать ошибку при отрисовке дизайна - дешевле, чем во время натягивании очередной фичи бекендерами.

Вывод: всегда исходить из задачи, целей и ресурсов. Знание html нужно в любом случае, backender вы или frontender. А сверстанный голый статический html имеет гораздо более высокий показатель переиспользования, чем шаблон друпала.

Если есть опыт, то railstutorial Майкла Хартла - хватит с головой, освоить за неделю-две
А дальше, уже исходя из предметной области, смотреть специализированные вещи.

На мой взгляд, агил веб девелопмент, где 400 страниц создают магазин, рассказывая о том, что такое аякс и jquery.ui - лишнее.

https://github.com/yaroslav/russian

В поиске довольно много ответов по этой проблеме. Ни один не подошел?
Где пишут, что рестарт надо делать, где - что это легаси омниауса.

Свиду, вроде, все правильно, но:
1. Что за ссылка localhost:8080/users/auth/vkontakte.user ? Обычно она выглядит как localhost:8080/users/auth/vkontakte
2. Для чего аттр_акссессоры у юзера?
3. Почему идентифицируете пользователя по ссылке, а не по паре провайдер+uid ? Люди любят менять никнеймы
4. Это опечатка?
resource_name, provider:provider

provider передается как параметр, а не как часть хэша. Вот скопировал из своего рабочего проекта:

link_to "Sign in with #{provider.to_s.titleize}", omniauth_authorize_path(resource_name, provider)

Во-первых, сделайте

# config/routes.rb
resources :tasks do
 match :complete_todo, on: :member, as: :finished_task, via: :post
end

А дальше, пока непонятно, что за ошибка и где. Порядок дебага:
1. Убедиться, что существует нужный роут и формируется правильная ссылка с правильным методомо (пост, гет) и форматом (html, js и т.д.)
2. Убедиться, что запрос попадает в нужный экшн
3. Убедиться, что таск выбран

Про попытке отметить задачу выполненной вылетает ошибка: param is missing or the value is empty: task

Непонятно, ошибка на клиенте или на сервере. Непонятно, что за ошибка (у эксепшенов есть классы). Непонятно, в каком месте возникает (у эксепшенов есть трейс)

Ну, а вообще, скорее всего, вы забыли про стронг парамс и просто так написали:
@task.update(task_params)

и не обновили сам метод:

private
def task_params
params.require(:task)
...
end

Или вообще не написали его

resque, sidekiq, delayed_job
+
whenever, clockwork