При использовании архитектуры в стиле вертикальных слайсов рано или поздно встает вопрос «а что делать, если появляется код, который нужно использовать сразу в нескольких хендлерах?»

TLDR: нужно создать промежуточный слой обработчиков и добавить специализированные маркерные интерфейсы, чтобы было ясно, какие обработчики — холистические абстракции, а какие нет.

Ответ на этот вопрос не всегда очевиден. Джимми Боггард, например, предлагает «просто использовать приемы рефакторинга». Я всецело поддерживаю такой подход, однако форма ответа видится мне такой же обескураживающей, как и предложение воспользоваться свободной монадой для внедрения зависимостей в функциональном программировании. Такая рекомендация точна и коротка, но не слишком полезна. Я попробую ответить на этот вопрос более развернуто.

«Сделайте нам фильтры «как в экселе», — довольно популярный запрос на разработку. К сожалению, реализация запроса в общем виде «слегка» длинее, чем его лаконичная постановка. Если вдруг вы никогда не пользовались этими фильтрами, то вот пример. Основная фишка в том, что в строчке с названиям колонок появляются выпадающие списки со значениями из выбранного диапазона. Например в колонках А и B — 4000 строк и 3999 значений (первую строчку занимают названия колонок). Таким образом, в соответсвтующих выпадающих списках будет по 3999 значений. В колонке C — 220 строк и 219 значений в выпадающем списке соответственно.

Всем привет! Меня зовут Григорий Дядиченко, и я всё ещё разрабатываю проекты на Unity под ключ. Сегодня хочется поговорить про полезный инструментарий для Unity разработчика. У меня давно на эту тему есть свой топ ассетов или софта, которые используются почти в каждом проекте, плюс несколько своих утилит. Не будем касаться слишком широких и банальных инструментов типа adb, а составим некоторый набор того, что можно использовать почти в каждом проекте.

Генерация идеального лабиринта

Interactive rebase — один из самых универсальных инструментов Git'а. В этой статье от автора Git-клиента Tower рассказывается, как корректировать сообщения при коммитах и исправлять свои ошибки.

Содержание

• О разделяемых ресурсах
• Возможные проблемы при работе в многопоточной среде
  • Deadlock
  • Race-Condition
  • Busy-Wait
  • Thread Starvation
• Средства синхронизации
  • Interlocked
  • Monitor.Enter, Monitor.Exit, lock
  • SpinLock, SpinWait
  • Monitor.Wait, Monitor.Pulse[All]
  • ReaderWriterLockSlim
  • Семейство ResetEvent
• Выводы

В этом туториале мы освоим паттерн проектирования “Команда” (Command) и реализуем его в Unity в рамках системы перемещения игрового объекта.

Запросы, приказы и команды: все мы знакомы с ними в реальной жизни; один человек отправляет запрос (или приказ, или команду) другому человеку выполнить (или не выполнять) некоторые задачи, которые ему поручены. В проектировании и разработке программного обеспечения это работает аналогичным образом: запрос одного компонента передается другому для выполнения определенных задач в рамках паттерна Команда.

Предисловие

Разбираем кадр

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

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

И вот, среди прочих родилась простая идея: "А почему бы не автоматизировать отслеживание новых выпусков ИТ-подкастов с помощью Telegram-бота и GitHub Actions? Чтобы просто подписаться на telegram-канал и получать актуальные выпуски подкастов по мере их выхода.

Конечно, можно скачать специализированные приложения, типа "Poket Casts", либо подписаться на RSS, но лично для меня использование Telegram-канала является самым удобным, простым и привычным.

Так был создан telegram-канал @awesome_russian_podcasts, куда в автоматическом режиме публикуются новые выпуски множества ИТ-подкастов, собранных в моём репозитории. Собственно, о процессе создания этого канала (его техническую часть) я и хочу рассказать далее.

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

В этой статье мы рассмотрим, какие методы используется для того, чтобы игра, написанная на Unity, могла запускать сторонние моды: модификации библиотек игры и самого движка, подмена адресов в таблице импорта dll, вмешательство в загрузку Mono Runtime и другие.

Сколько уже было мануалов "Как сделать игру на Unity за 3 часа", "Делаем Counter-Strike за вечер" и т.п.? Низкий порог входа — это, несомненно, главный плюс и минус Unity. Действительно, можно накидать “ассетов”, дописать несколько простых “скриптов”, обмотать синей изолентой и это даже будет как-то работать. Но когда проект обрастает игровыми механиками, сложной логикой поведения, то проблемы при подобном подходе нарастают как снежный ком. Для внедрения новых механик требуется переписывание кода во многих местах, постоянная проверка и переделывание префабов из-за побившихся ссылок на компоненты логики, не говоря уже об оптимизации и тестировании всего этого. Разумеется, архитектуру можно продумать изначально, но на практике это всегда недостижимая цель — дизайн-документ довольно часто меняется, какие-то части выкидываются, добавляются абсолютно новые и никак не связанные со старой логикой поведения. Компоненты в Unity — это шаг в правильном направлении в виде декомпозиции кода на изолированные блоки, но особенности реализации не позволяют достичь необходимой гибкости, а самое главное, производительности. Разработчики придумывают свои фреймворки и велосипеды, но чаще всего останавливаются на ECS (Entity Component System). ECS – одно из решений, продолжающее идею компонентной модели Unity, но придающее ей ещё больше гибкости и сильно упрощающее рефакторинг и дальнейшее расширение приложения новым функционалом без кардинальных изменений в текущем коде.

Эта статья — гостевая публикация от ребят из Test IT

Для начала разберемся, что такое MVP (Model View Presenter)

Зачем же он нужен? Самый простой ответ — для постройки удобной и расширяемой архитектуры.

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

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

Представим простой пример. У нас есть игра slasher с монстрами. У нас есть несколько режимов: easy, medium, hard. Следовательно пусть у нас будут отличаться у монстров жизни и урон. Как организовать удобное создание монстров и в одном месте? Все в подcut`e.