Robert

На рубиконфе Matz говорил что есть идеи сделать статическую типизацию.
Вот тут почитать можно.

Маловероятно.
Есть язык crystal-lang.org который стараются сделать максимально приближенным к руби. Вот там, возможно.

P.S. Да, на самом сайте написано, что такого никогда не будет, но версия 0.7 и мало ли что еще изменится. Дискуссии там вроде совершенно разные ведутся по разным аспектам развития.

1. Сохраняем дамп базы данных.
2. Добавляем все статические файлы в архив.
3. Сохраняем 1),2) себе на компьютер.
4. В место сайта делаем заглушку типа "Бла бла бла мы закрылись. Если что пишите vnikuda@domain.com"

Либо попросить хостера с этим помочь.

Или я что-то не так понял и всё на много сложнее?

А как защититься от того, что человек может много-много раз нажать кнопку F5 ?
Тут уже смотря какие цели преследуете.

Хотите, что б он случайно не нажал и трафик не тратил свой? Поставьте javascript проверку, что б не лайкать лайкнувшие записи

Хотите, что б не мог накрутить лайки? Ставьте проверки на стороне сервера: по логину, айпи, сессии...

Хотите, что б не спамили ? Ну, тут уже находите золотую середину на ограничение количества запросов с одного айпи\сессии\юзера и т.д. и т.п.

Но вообще, в том формате, что вопрос задан - это бессмысленная преждевременная оптимизация. Запрос вам всегда и кто угодно может отправить - вы же публичный сайт делаете.

Есть 2 крутых инструмента, это Capistrano и Mina. Не буду тут описывать пошагово инструкцию, так как очень много статей по этому поводу уже было написано и на хабре и просто в просторах интернета. Я всегда пользовался капистрано, но читал про мину, вроде как она быстрее деплоит.

P.S. если останутся вопросы пиши лично - расскажу.

Вы не написали что хотите получить. Вообще само создание файла разумнее куда-нибудь вынести из контроллера, чтобы было удобно тестировать и запускать из фоновых задач.

При отдаче файла его не нужно сохранять в public папку, а так же желательно удалять его после отдачи, чтобы не занимал место. Обычно для этого используют Tempfile

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

Не учите технологии. Учитесь решать задачи. Особенно с исходными данными и запасом прочности.
Мне кажется, есть 2 пути успеха в айти сегодня:
1. Рвение к чему-то конкретному (например, нейронным сетям, компьютерному зрению, машинному обучению, электронной коммерции, визуализации ... ) - тут, судя по последнему абзацу, мимо кассы
2. Не знание технологий или даже стеков, а умение решать практические задачи. Вот тут очень похоже, что оно.

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

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

На выходе, даже если не сделаете новый супер-хит, то:
1. Познакомитесь со всеми технологиями и приемами (где-то больше, где-то меньше)
2. Будет опыт в реальном технологическом процессе

P.S. Если все же интересует именно только екоммерс и интернет-магазины (не самая привлекательная часть айти, на самом деле), то не рвитесь сразу верстать шаблоны под битрикс. Найдите важные задачи для бизнеса, которые не решаются стандартными методами (их уймы) и попробуйте решить одну из них.

Если статусов будет только два (Обработан/Не обработан), то достаточно булеана.
Если статусов будет много, то лучше прикрутить state-machine (AASM/Workflow). В этом случае можно будет сделать, чтобы на в разных статусах были доступны разные действия с заказом.
Если статусов будет много, но стейт-машина избыточна (или лень возиться с ней), то можно воспользоваться стандартной рельсовой фичей enum (edgeapi.rubyonrails.org/classes/ActiveRecord/Enum.html).

Создавать отдельную модель как-то совсем избыточно. Только если там ещё какой-то функционал будет, но сходу придумать какой-то пример не могу.

Обычно в таких случаях так же работают и над тем, чтобы изменить информацию пользователей (обычно поместить в нужные столбцы нужных таблиц) так, чтобы приложение продолжало корректно функционировать. Лучший способ это проделать - взять базу от продакшена и в девелопмент-среде проделать над ней все действия. Ну а дальше уже обновлять продакшен.

Слабо понимаю, чем код вьюх и абилити здесь поможет.
Если без аякса
Но, скорее всего, у вас в контроллере есть
redirect_to ..., error: 'Error message'
или
flash ..., error: 'Error message'

Так вот нужно использовать
flash.now.error = 'Error message'

Если с аяксом
Должен быть темлейт action.js.erb
или в самом скрипте должна быть обработка error события.
И там нужно вручную вызывать нужное сообщение. Типа:
$("#error").text('Error message').show();

Самый простой вариант (если не критичен временный простой) это отключить старый сервер, завести новый и переключить dns.

При более сложных вариантах (без простоев) можно настроить новый сервер БД и зеркалировать весь трафик на новую БД. В остальном все тоже самое, настраиваем новый сервер и переключаем dns.
В обоих случаях лучше заранее убавить TTL в dns.

Раз уж пишете на руби, то пишите правильно

@songs = Mainstack.all( :order => [:id.desc]).map { |m| m.song }

Ну а сортировку можно так сделать

@songs = Song.all(:order => [Song.mainstacks.id.desc])

Ведущий слэш не нужен и уберите описания роутов для email в конец файла. Порядок следования определений роутов имеет значение, чем ближе к верху файла тем выше приоритет, т.е. более частные случаи должны быть выше чем общие.

Потому что каждый раз при деплое Capistrano создает новую директорию, в которую загружается свежий релиз вашего приложения. Соответственно, ваши изображения остаются в старой директории. Вам нужно настроить в файле deploy.rb симлинк с папками, в которых будут храниться изображения, сами эти папки обычно хранятся в директории shared выше по дереву относительно директории, содержащей релизы. Надеюсь, понятно объяснил :)

И судя по тому, что информация в БД у вас затирается, вы используете SQLite3 в качестве базы данных. Локум предоставляет для каждого проекта базу данных на PostgreSQL, MySQL или какую-то еще на выбор, рекомендую перебраться в PostgreSQL. Эта БД - де-факто стандарт для приложений на Rails, хотя иной раз выбор зависит от проекта. А SQLite - это только для этапа, когда разработка на Rails только-только постигается. Раньше переберетесь - проще будет в дальнейшем.