ssidelnikov

1. Админка для Rails приложения есть в самом Rails — scaffold.
2. Я против использования ЦМС в средах с высокой абстракцией, тем более когда речь идет о средах с настолько высоким уровнем вложенного функционала как Rails. Поясню.
Вам нужен набор для рисования — ЦМС-стайл (в него входит, карандаши 65536 уветов, краски 16м цветов, фломастеры, аэрограф, кисти из 100500 видов шерсти животных, чертежная доска, студия по улице набережная д17, кв 33 с пассивным и активным освещение, заказанная выставка в Париже с открытой датой, 5 предоплаченных лотов в любом из аукционных домов Кристис, Сотбис, Бонхамс на выбор, оплаченные билеты на самолет.
Но если вам нужно рисовать на стене соседнего дома, абстрактные картины баллончиком, то все это вам не нужно вообще.
Не смотря на то что это все называется емким словом: «Искусство», вам этот ЦМС… ммм… не совсем подходит.
Вам не нужны оплаченные билеты на самолет, вы больше времени потратите если будете их сдавать в авиакассу, чтобы вам не названивал оператор:«Вы чо ваще, собираетесь лететь, не?». Вам нужена пара гемов, подъемник и балончик с краской. Зачем ради этого городить ЦМС я не понимаю. Вам достаточно написать в Gemfile

gem 'spray-paint'
gem 'lift'

и эти гемы есть, вы же не единственные кто пытается заниматься рисованием баллончиком с краской.
Тем более что прикручивать spray-paint и lift к ЦМС всеравно придется. А проблемы есть, и в цмс и без нее, и размер их одинаков, и никуда эти проблемы не денутся.

3. последний магазин который я использовал содержал:

gem 'devise' # аутентификация
gem 'haml-rails' # HAML вместо HTML
gem 'sass-rails' #sass вместо css
gem 'coffee-rails' #coffeescript вместо javascript
gem 'postmark-rails' # рассылка почты
gem 'russian' # потому что мы русские
gem 'paperclip' # для обработки картинок
gem 'delayed_job_active_record' # для отложенных задач
gem 'delayed_paperclip'    , '2.4.5.2', :git => 'git://github.com/tommeier/delayed_paperclip', :branch => 'fix_312' # для отложенной обработки(ресайза) картинок
gem 'rufus-scheduler' # типа крон, только внутри рабочего rails приложения
gem 'twitter-bootstrap-rails' # чтобы сверстать все, включая админку
gem 'aws-sdk' # для выгрузки картинок на S3
gem 'quiet_assets' # чтобы логи не шумели

админка генерируется через rails g scaffold…
ничего лишнего, всего достаточно

Почтовый сервер sendmail считает почтовый домен локальным (то есть обрабатывает почту для данного домена) в следующих случаях, если на сервер указывают записи:
— Запись A или MX в прямой зоне DNS (проверяется командой host имя.домена)
— Hostname сервера
— Записи в /etc/hosts
— Записи в обратной зоне DNS (проверяется командой host ip-address)
— Записи в /etc/mail/local-hosts-names, /etc/mail/virtusertable и непосредственно имя домена может быть определено в конфигах sendmail (hostname.mc, sendmail.mc и из него который создается sendmail.cf — команда grep -i domain /etc/mail/* найдет эти записи.

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

1. В первые мгновения js нет ни у кого. JavaScript ведь загружают в конце страницы, чтобы контент был доступен раньше, и пока файлы не загрузятся, js у пользователя не работает. Поэтому сайт, работающий без js, будет доступен пользователю раньше. А если соединение медленное, или какая-то ошибка сети, то сайт, не работающий без js, не будет работать у пользователя совсем. Альтернатива — помещать js наверх, хотя как это поможет. Сайты, поддерживающие людей без js, позволяют получить содержание страницы раньше => работают быстрее.

2. Ошибка в js-файле может привести к тому, что сайт станет недоступен. Это замечание кажется довольно очевидным, но ему часто придают неоправданно мало значения. Если js сжимается в 1 файл, чтоб он грузился быстрее, то при ошибке в одном из скриптов весь оставшийся js тоже не выполнится.

Проблемы с сетью, какой-то js-файл не загрузился — сайт не работает.
Забыли запятую — сайт не работает для всех пользователей IE.
Забыли отладочный console.log — сайт не работает, если отладочные инструменты не установлены и не включены (Firefox, Safari, Internet Explorer).
Ну и т.д. Сторонний js от рекламодателей, который нельзя контролировать, может сломать сайт.

Можно, конечно, сказать, что нужно писать код без ошибок. Но такого кода не бывает. Проблема тут в архитектуре, веб работает не так. Недавно, к примеру, Lifehacker и Gizmodo были полностью недоступны продолжительное время именно из-за ошибки в js. Можно вот тут еще почитать: isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs

В большинстве случаев предоставить альтернативу без js совсем не сложно ведь — пишем просто unobtrusive js. Если это кому-то важно, то для таких страниц и тесты писать проще.

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

А вот когда такого предупреждения нет, то очень беситпосетителю непонятно, что то, что он видит в окне браузера вовсе не то, что разработчик хочет ему показать.