DM2 на прокачку | ходы игроков | Нюансы разработки

Загадка буквы Ё

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

Так в чём же всё-таки было дело? Оказалось, это не проблема кодировки. Причина была в том, что при создании модуля его название проверялось на допустимые символы огромным регулярным выражением, а при редактировании нет. Была мысль, что это могло быть сделано для защиты от какой-то хакерской атаки, но выяснилось, что проверка полностью выполнялась на клиентской стороне: можно было просто отключить Javascript в браузере и создавать модули хоть с Ё, хоть с залго-символами. После обсуждения было решено эту регулярку просто убрать.

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

Длинный список ассистентов

На ДМе не всегда есть возможность красиво реализовать именно то, что хочется. Со списком ассистентов именно такой случай. Его, естественно, получилось по умолчанию скрыть, но не получилось полностью очистить от неактивных пользователей.

Написать запрос, который будет вытаскивать только активных за последний месяц пользователей, не трудно, и он у меня даже готов, но проблема в том, что он медленный, и нет хорошего способа закэшировать результат. Медленный он потому, что дата последней активности хранится в базе в сериализованном виде, да ещё и бонусом в XML формате. А закэшировать трудно потому, что нет хорошего события, по которому можно было бы сбрасывать этот кэш.

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

В итоге вышло решение из разряда "лучше чем ничего": список сократился почти в 2 раза, но всё ещё содержит несколько тысяч пользователей.

Правда вот сейчас появилась идея кэшировать его просто по таймеру, подумаем...

Спойлеры старого образца

В одном из последних обновлений был пофикшен баг с добавленной кнопкой "Раскрыть/скрыть все спойлеры". Его, как и ещё один баг, нашёл Бродяга, за что ему спасибо. Некоторые спойлеры просто не раскрывались, и в своём посте он сделал логичное предположение, что это может быть из-за огромных текстовых блоков под спойлерами и спойлеров в спойлерах. Но нет, дело оказалось в другом.

Первая версия скрипта для раскрытия-скрытия спойлеров искала их по классу "spoiler-tag", который был назначен родительскому DIV. Оказалось, что этот класс появился только вместе с добавлением тэга NSFW, что, судя по всему, произошло в 2020 году. Посты на ДМе хранятся в HTML формате, поэтому никакие изменения ретроспективно к ним не применяются. Как итог, скрипт просто не видел такие спойлеры.

Пофикшено переписыванием скрипта таким образом, чтобы он искал спойлеры без привязки к классу.

Как проходит разработка

Как известно, ДМ2 написан на ASP.NET Web Forms. Рекомендованной средой для таких проектов является Visual Studio Community, её я и использую. Она позволяет сбилдить код ДМа и запустить его локально. То есть, пока я занимаюсь разработкой, у меня на localhost крутится свой собственный ДМчик с коннектом к тестовой базе.

Во время разработки всегда приходится править как aspx страницы, так и code behind, который написан на C# и реализует всю основную логику. JavaScript используется относительно редко, также зачастую он не вынесен в отдельные файлы, а просто вшит в aspx страницы. Естественно, не обходится без CSS, однако большинство стилей уже вынесены в файлы тем, так что с ними попроще.

Иногда приходится что-то добавлять или изменять в тестовой базе, как в случае с Telegram и Discord уведомлениями. Для этого используется SQL Server Management Studio (SSMS).

Сам процесс разработки проходит довольно стандартно: я пуллю себе dev ветку из репозитория, вношу и тестирую все изменения локально, пушу их в новую ветку, создаю pull request в dev, сам же его аппрувлю и мерджу (полноценный код ревью - непозволительная роскошь, все потенциально стрёмные моменты оговариваются отдельно). После этого требуется Лекс для пересборки тестового сервера. Когда пересборка завершается, команда администрации и ещё несколько добровольцев (в основном те, кто интересовался разработкой ДМ3) тестируют изменения. Если всё ок, изменения аналогичным образом деплоятся на прод, то есть на основной сервер. Кроме того, Лекс переносит все изменения с тестовой базы, если они есть.

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

Эмодзи в инвентаре

Многие знали, что до последнего обновления некоторые эмодзи в инвентаре ломали отправку постов. Почему именно в инвентаре, а не в других полях? Потому что под полем отправки поста есть экспресс-редактор инвентаря.

При этом отправка постов ломалась не из-за любых эмодзи, а только из-за тех, код которых состоит из пяти символов. Тут всё дело в том, что ASP.NET считает такие символы опасными, из-за чего срабатывает автоматическая защита. Чтобы этого не происходило, их нужно кодировать специальным образом.

Однако быстрая проверка показала, что функция кодирования уже и так вызывалась для всех полей, в том числе и для экспресс-редактора инвентаря, поэтому пришлось копать... В итоге в плане кодинга фикс оказался максимально простым: перенести буквально 3 строчки кода из одного места в другое. Интересный момент, почему. Всё из-за того, что экспресс-редактор реализован не через обычное обновление страницы, не через UpdatePanel, которая позволяет обновлять только часть страницы, и даже не через какой-то хитрый JavaScript, а через прерывание запроса О_О

То есть код делает все нужные действия, используя элементы страницы, но в правильный момент полностью останавливает своё выполнение. Из-за этого становится критически важным порядок, в котором он эти самые действия выполняет. Если его не соблюдать, можно получить значения, которые стриггерят автоматическую защиту. В общем, код ДМа не перестаёт удивлять оригинальными решениями.

Что хранят контролы

Контролы в ASP.NET – это серверные элементы управления, которые отображают содержимое на странице и часто обеспечивают с ним какое-то взаимодействие пользователя. Они объявляются на странице, а потом с ним можно делать, что хочешь, в code behind. Для отображения простого HTML содержимого часто используется контрол Literal.

Если мы возьмём литералы litBody и litComment, в которых мы хотим отображать текст и комментарий поста, то мы можем сделать это примерно так:

litBody.Text = "‹div›Это пост!‹/div›";
litComment.Text = "‹div›А это комментарий!‹/div›";

В таком виде всё смотрится неплохо, но в коде ДМа не всегда соблюдается принцип разделения данных. Из-за этого, например, после фикса отображения приватов некоторое время страница оценённых постов выглядела так:


Всё потому, что именно на этой странице код не такой, как в примере выше, а примерно такой:

litBody.Text = "‹div›‹div›Это пост!‹/div›";
litComment.Text = "‹div›А это комментарий!‹/div›‹/div›";

То есть litBody и litComment не содержат целостных блоков данных. Вместо этого подразумевается, что они будут использоваться только в паре и в нужном порядке. Такое довольно трудно заметить, особенно когда на всех остальных страницах подобного нет. Собственно, я и не заметил, из-за чего закрывающий DIV был пропущен. Сработал механизм, который автоматически закрывает открытые тэги в конце родительского блока, и мы получили такой непривычный вид страницы.

К слову, всего на ДМе аж 8 разных страниц, которые отображают комментарии к посту.