Спасибо, как найду немного свободного времени — займусь

Спасибо. Хорошая, грамотная и весьма полезная статья.
С удовольствием прочту еще что-то из этой серии.

«Code of Conduct» — это полный финиш, я с вами полностью согласен.

> А еще есть довольно много спикеров, которые принципиально не участвуют в конференциях без CoC.
Я подозреваю одну персону ради которой это все и было сделано. Не думаю что от личного присутствия этого человека мы что-то потеряли.

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

Объясните пожалуйста, какую предметную область вы хотите отразить? Не совсем понятно, какую идеалогическую базу вы здесь вообще используете? На основе каких суждений вы ВНЕЗАПНО перевели повествование все в плоскость ООП?

рад что пригодилось

Виски от Suntory действительно космос. ИМХО, Довольно красивый PR ход соответствующий вкусовым качествам

— Сколько шариков для гольфа поместится в школьный автобус?
— два
— почему?
— а что, думаете, не поместится?

Кас, прекрати :D

На своих проектах имею с MegaIndex следущую проблему

An ActionView::Template::Error occurred in tags#show:
incompatible character encodings: UTF-8 and ASCII-8BIT

Parameters: {«controller»=>«tags», «action»=>«show», «tag»=>"\xD0\x9A\xD0\xBE\xD0\xBD\xD0\xBA\xD1\x80\xD0\xB5\xD1\x82\xD0\xB8\xD0\xB7\xD0\xBC"}

мы попрощались с этим товарищем

  if ($http_user_agent ~* (MegaIndex) ) {
    return 403;
  }

а потом для изменения работы политик доступа (уже существующей и функционирующей системы) необходимо пригласить программиста

вы процитировали текст вне контекста. Я говорил о политиках доступа, определяемых ACL. Я нигде не заявлял, что система все сделает сама. Ответ на ваш вопрос простой — никак. Ваша система может обладать множеством критериев доступности операции, которые не укладываются в перечень 10 фундаментальных критериев персонального и группового доступа.

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

Если совпадает, значит все привилегии ему на стол

это далеко не всегда так. Проверка на Владение это лишь один из возможных критериев и его вполне себе можно не использовать в ряде систем.

за кадром осталось, кто отвечает за обновление поля USER_ID заданного объекта

Стандартный подход организации связи владелец-объект в рельсе: User has_many Pages + Page belongs_to User. За этот и другие виды связей отвечает разработчик.

проверяться могут отдельные поля, группы полей

если я правильно вас понимаю и вам интересна интергация со strong_parameters или нужен контроль отображения полей в форме — то это тоже довольно легко реализовать.

неоконченая аспирантура?

o_O Ну да, я не защищался, за отсутствием какого-либо влияния на мое будущее. Но сделать такой вывод из статьи — это сильно :D

не обнаружил хотя бы минимального сравнения с CanCan

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

спасибо. Суть понятна

И еще пару вопросов, если позволите

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

2) как вы формируете слаги (ЧПУ)? я так понимаю генерировать их вам не приходится? Не читаю ленту, но по всей видимости там числовые ID в урлах.

3) Вопрос вне контекста тех. инструментария.
Если ли трудности при расчете релевантного контента для каждой публикуемой статьи. Я про блоки с названиями вроде: Читайте так же; По этой теме;

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

PS: если вы планируете и дальше освещать вопросы устройства издательских систем, то обещаю быть одним из самых преданных ваших читателей, т.к. именно этим целенаправленно занимаюсь несколько последних лет. За поднятую тему огромное спасибо!

спасибо.

> наличие картинки или ожидание действия бильд-редактора
Фактически, это может быть таким же важным признаком публикации, как и сам статус публикации. И потому, особенно интересно какова ваша практика управления состояниями публикации, т.к. это один из самых интересных организационных вопросов (по крайней мере для меня лично).

Как правило, CMS издательской системы предполагает изменение статусов публикаций. Часто, у издателей есть особые пожелания на этот счет. Соответственно, используются некоторые известные решения.

Правильно я понимаю, что в вашей CMS очень простая система статусов, вида — Черновик/Опубликовано?

Пожалуй, самое интересное интервью. Равиль, спасибо.

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

Спасибо, что продолжаете!

Продолжайте пожалуйста. Интересная тематика. Было бы здорово, если бы были примеры из реальной практики.