Привет Хабр!

В этой статье я хочу раскрыть механику создания онлайн сессии и подключения к ней. Все выполнено в с использованием Online Subsystem для возможного расширения вашей игры в контексте Steam, Origin, Play Station Store и т.д

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.

Эта статья родилась случайно. Слоняясь по книжному фестивалю и наблюдая, как дочка пытает консультантов, заставляя их искать Иэна Стюарта, мой глаз зацепился за знакомые буквы на обложке: "Nginx".

Надо же, на полках нашлось целых три книги - не полистать их было бы преступлением. Первая, вторая, третья... Ощущение, будто что-то не так. Ну вроде страниц много, текст связный, но каково содержание? Установка nginx, список переменных и модулей, а дальше docker, ansible. Открываем вторую: wget, лимиты запросов и памяти, балансировка, kubernetes, AWS. Третья: GeoIP, авторизация, потоковое вещание, puppet, Azure. Ребята, а где про то, как вообще работает nginx? На кого рассчитаны ваши книги? На состоявшегося админа, который и так знает архитектуру этого веб-сервера? Да он вроде с базовыми настройками и сам справится. На новичка, который не знает как пользоваться wget? Вы уверены, что ему знание о существовании ngx_http_degradation_module и тем паче "облака" важнее порядка прохождения запроса?

Итак. О чем не пишут в книгах.
(здесь и дальше мы говорим только о NGX_HTTP_)

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Эта статья посвящена наиболее часто используемым комбинациям клавиш при работе в командной строке Linux (в основном в командном интерпретаторе bash).

Она точно будет полезна начинающим своё знакомство с Linux и, уверен, пригодится тем, кто уже имеет опыт (не всегда годы практики учат работать быстрее).

Никогда не развивал навыка быстрой печати, но знание не одного десятка hotkey'ев, перечисленных в этом материале, позволяет набирать команды со скоростью мысли.

Я попытался продемонстрировать многие примеры при помощи анимированных gif'ок – иногда несколько кадров больше скажут, чем несколько абзацев текста.

Одна из самых простых и базовых концепций в программировании игр — это идея игрового цикла. При запуске вашего проекта происходит его инициализация, после чего игровой цикл действует до тех пор, пока игрок хочет продолжать игру: каждый кадр вы обрабатываете ввод, обновляете состояние игрового мира и выводите результат на экран. Когда игрок закрывает игру, происходит очистка данных, и на этом все заканчивается. 

Но когда вы пишете игровой код на Unreal Engine, вы не имеете дело с игровым циклом напрямую. Вы не начинаете работать сразу с основной функцией — сначала вы определяете подкласс GameMode и переопределяете функцию под названием InitGame. Или пишете одноразовые классы Actor и Component и переопределяете их функции BeginPlay или Tick для добавления собственной логики. Это самый минимум того, что вам нужно сделать: обо всем остальном движок позаботится за вас.

Unreal Engine также предлагает вам как программисту мощный и гибкий инструментарий: конечно, он имеет открытый исходный код, но также возможно и расширение несколькими другими способами. Даже если вы только начинаете работать с этим движком, было бы не лишним получить представление о его GameFramework: о таких классах, как GameMode, GameState, PlayerController, Pawn и PlayerState.

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

Суть статьи очень простая - архитектор представитель бизнеса в разработке. Его амбассадор. Проводник мысли продакт-менеджера во все укромные уголки проекта. Продакту нужно дружить с архитектором. Быть с ним на одной волне. Только так он сможет получить ожидаемый результат.

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

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

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

В процессе эволюции нашей библиотеки компонентов Taiga UI мы стали замечать, что некоторые компоненты посложнее имеют @Input просто для того, чтобы прокинуть его значение в @Input другого нашего базового компонента внутри себя. Иногда встречается такая вложенность даже в три слоя.

Мы справились с помощью хитрых директив, которые назвали контроллерами. Они полностью решили проблему вложенности и сократили вес библиотеки.

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

Возможности C# из года в год становятся всё шире. Разные фичи делают жизнь программиста приятнее, но предназначение и особенности некоторых из них могут быть очевидны не всем. Например, старый-добрый yield. Для некоторых разработчиков, особенно начинающих, это самая настоящая магия – непонятная, но интересная. В данной статье будет показано, как же всё-таки работает yield, и что на самом деле скрыто за этим волшебным словом. Приятного чтения!

Хочу рассказать, как автор кода может упростить работу ревьюеру и увеличить тем самым как качество ревью, так и производительность ревьюера. Эта статья вполне может использоваться в качестве в вашей внутрикорпоративной документации как руководство для подготовки изменений к ревью. Она, собственно, и была скомпилирована из такого руководства.

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

public interface ISpecification
{
    bool IsSatisfiedBy(object candidate);
}

Что с ним не так применительно к C#?

1. Есть Expression<Func<T, bool>> и Func<T, bool>>, сигнатура которых совпадает с IsSatisfiedBy
2. Есть Extension-методы. alexanderzaytsev с помощью них делает вот так:
   
   

   public class UserQueryExtensions 
   {
     public static IQueryable<User> WhereGroupNameIs(this IQueryable<User> users,
   string name)
     {
         return users.Where(u => u.GroupName == name);
     }
   }
   

   
   
3. А еще можно реализовать вот такую надстройку над LINQ:
   
   

   public abstract class Specification<T>
   {
     public bool IsSatisfiedBy(T item)
     {
       return SatisfyingElementsFrom(new[] { item }.AsQueryable()).Any();
     }
   
      public abstract IQueryable<T> SatisfyingElementsFrom(IQueryable<T> candidates);
   }
   

В конечном итоге возникает вопрос: стоит ли в C# пользоваться шаблоном десятилетней давности из мира Java и как его реализовать?

Время от времени я встречаю людей, пытающихся выразить API в терминах IQueryable<T>. Почти всегда это плохая идея. В этой статье я объясню почему. Вкратце, IQueryable<T> — это один из лучших примеров заголовочного интерфейса (Header Interface), предлагаемых платформой .NET. Его почти невозможно реализовать полностью.

Эта статья о проблемах реализации API на основе интерфейса IQueryable<T>. Это не претензия к интерфейсу как таковому. Кроме этого, это не претензия к замечательным методам LINQ, доступным для интерфейса IEnumerable<T>.

Можно сказать, что IQueryable<T> — это одно сплошное нарушение принципа подстановки Лисков. Я буду использовать закон Постела, чтобы объяснить почему это так.

Принцип устойчивости, также известен как закон Постела в честь Джона Постела: «Будь либерален к тому, что принимаешь, и консервативен к тому, что отсылаешь (Be liberal in what you accept, and conservative in what you send)».

Эта статья является конспектом материала Effective Aggregate Design Part I: Modeling a Single Aggregate.

Объединение сущностей (entities) и объектов значений (value objects) в агрегат с тщательно продуманными границами согласованности может показаться простым, но из всех тактических DDD шаблонов, агрегат является одним из самых сложных.

Для начала будет полезно рассмотреть некоторые общие вопросы. Является ли агрегат просто способом объединения тесно связанных объектов с общим корнем (Aggregate Root)? Если да, то есть ли какое-то ограничение на количество объектов, которые могут находиться в графе? Поскольку один агрегат может ссылаться на другой, можно ли перемещаться по агрегатам с помощью этих связей и менять данные объектов, входящих в определенный агрегат? И чем является инвариант и граница согласованности? Ответ на последний вопрос в значительной степени влияет на остальные ответы.

Есть множество способов смоделировать агрегат неправильно. Мы можем спроектировать слишком большой агрегат. С другой стороны, мы можем разделить все агрегаты так, что в результате нарушатся истинные инварианты. Как мы увидим, крайне важно избегать подобных крайностей и вместо этого обращать внимание на бизнес-правила.

Эта статья является конспектом материала Effective Aggregate Design Part II: Making Aggregates Work Together.

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

Мы можем захотеть использовать композиционную структуру во время проектирования агрегатов. Такая структура позволит нам обходить глубокие графы объектов. Однако это не должно быть целью. DDD утверждает, что один агрегат может содержать ссылки на корень других агрегатов. Но это не значит то, что агрегаты входят в границу согласованности другого агрегата, который на них ссылается. Ссылка не приводит к образованию единого агрегата.

В данной статье я хочу предоставить переработанную и упорядоченную выжимку документации по настройке tsconfig.json, которая, я уверен, будет полезна тем, кто только начинает свой путь в мире TypeScript или тем, кто до этого момента не нашёл времени и сил, чтобы разобраться в деталях и теперь хочет закрыть этот пробел.