Когда обслуживание сервера должно влиять на реализацию descisions?
Это возможно начиная с Rails 5 и Action Cable. Хороший учебник можно найти здесь:
https://blog.heroku.com/real_time_rails_implementing_websockets_in_rails_5_with_action_cable
Он включает создание «канала», на который подписывается каждый пользователь, однако гораздо проще пройти учебник, подобный приведенному выше, чем объяснять мне шаг за шагом. Вышеуказанное предназначено для создания комнаты чата, поэтому вы просто должны поменять новое сообщение на новое уведомление.
4 ответа
В целом, удобство использования продукта - это то, что заставляет людей выбирать между ним и аналогичными продуктами. Если продукт имеет плохое удобство использования, пользователи не будут заботиться о том, насколько качественным является его код - для них важно только то, насколько простым и эффективным является его использование и насколько хорошо он отвечает их потребностям.
Техническое обслуживание можно рассматривать как один аспект юзабилити. Я бы сделал приоритетом иметь легко обслуживаемый продукт. В долгосрочной перспективе это сэкономит много часов работы администраторов.
Один из способов обдумать это - сначала спроектировать наиболее подходящее решение с точки зрения конечного пользователя / администратора, а затем сделать его интеллектуальным вызовом. на самом деле реализовать это оптимальное решение. Вероятно, это потребует больше усилий от программиста, но конечный результат будет лучше.
Например, ZFS - это один продукт, в котором об обслуживании заботились хорошо (хотя я не использовал его лично). Когда он разрабатывался, было приложено много усилий, чтобы упростить администрирование файловой системы с помощью инструментов командной строки ZFS - и эти проектные решения затрагивают все уровни ZFS (например, пулы хранения).
В качестве другого примера я приведу Недавно планировал, как сделать обслуживание в моем будущем проекте - распределенной базе данных и сервере приложений. Размышления о том, как будут происходить типичные задачи администрирования (установка / обновление приложений, добавление / удаление серверов в кластере, устранение аппаратного сбоя и т. Д.), Помогли мне разобраться в некоторых дизайнерских решениях. Некоторые из них достаточно глубоко входят в архитектуру системы (например, как приложения и расширения загружаются во время выполнения,
Если я настраиваю систему единого входа для системы Windows, мне очень нравится использовать AD. В качестве системного администратора. Я стараюсь следовать политике единого источника данных. AD уже хранит большую часть моих данных о пользователях и безопасности Windows. Я предпочел бы иметь все там, а не вторую систему.
При настройке сред dev / test / prod я стараюсь максимально точно соответствовать среде Prod, особенно в той области, над которой работаем (где усилия по разработке ставятся и т. д.). Поэтому, если бы я настраивал систему для разработки интерфейса с AD, у меня, вероятно, было бы несколько серверов AD.
Какие варианты могут упростить администратора?
Можно ли иметь 1 главный сервер, который вы поддерживаете стандартным образом, и использовать что-то вроде процесса копирования VMware для поддержки всех или большинства других? Вместо того, чтобы делать что-то с 9 серверами, Сохраните остальные 8 в качестве копий этого зеркала мастера, за исключением изменений, внесенных для поддержки dev / test?
Можете ли вы запустить несколько доменов Dev или Test с 1 сервера AD?
Можете ли вы выполнить сценарий действий?
Можете ли вы уменьшить количество сред, особенно на более высоком конце теста? Например, предоставить несколько сред разработки и выпусков ролей вверх в один тестовый?
Use a provider pattern and abstract your datasource calls.
Then you can configure it to use AD or SQL on the fly.
public abstract SSODataProvider {
public bool AuthenticateUser(string u, string p);
}
public ADSSODataProvider : SSODataProvider {
public override AutheticateUser(string u, string p) {
//do auth here
}
}
public SQLSSODataProvider : SSODataProvider {
public override AuthenticateUser(String u, string p) {
//call DB
}
}
public static SSODataProvider dataProvider;
if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
dataProvider = new SQLSSODataProvider();
else
dataProvider = new ADSSODataProvider();
....
dataProvider.AuthenticateUser("sss","sss");
Почему бы просто не использовать OU вместо отдельных доменов при тестировании? То есть иметь один домен, но указать, что пользователи для определенных версий должны находиться в определенном подразделении внутри этого домена. Что бы вы делали в своих функциях поиска для поиска пользователей, вы бы указали конкретное подразделение в качестве корня поиска вместо корня домена. В каждом OU у вас могут быть идентификаторы, которые включают среду для сохранения их уникальности, например, user_env1_dev , user_env2_dev , user_env1_qa , ...
Я использую AD много для моих приложений и никогда не настраивал отдельные домены для разработки / тестирования.