Алоха всем.

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

А как быть интервьюерам? Какую задачу дать кандидату? Как понять сигналы, что кандидат «шарит»?

Я наткнулся на интересную статью по интервью на Senior инженера C++. Там у парня спрашивают базовую задачу FizzBuzz.

В этой статье мы рассмотрим бенчмарки различных решений на Java, начиная от простых вариантов и заканчивая многопоточными реализациями. Давайте разбираться вместе!

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

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

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

1. Определение целей. Спросите себя, чего вы действительно хотите. Это может быть цель стать Task Project Manager и руководить проектами. В этом случае стоит сконцентрироваться на собеседованиях на должности, предполагающие карьерный рост.  Если же вас больше интересуют разработка и архитектура, а от вопросов логистики,  тимбилдинга и управления инцидентами вы предпочитаете держаться подальше,  сосредоточьтесь на позициях, связанных с архитектурой и проектированием систем. Не забудьте о времени — реализация цели (карьерный рост, проектирование систем) должна укладываться в обозримый временной промежуток точно так же, как работа с кодом должна завершаться к дедлайну. 

Паттерн Компоновщик - так же известен как Дерево, Composite.

Суть паттерна

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

Проблема

Использование шаблона Composite имеет смысл только тогда, когда базовая модель вашего приложения может быть представлена в виде дерева.

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

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

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

Адаптер - это шаблон структурного проектирования, который позволяет объектам с несовместимыми интерфейсами взаимодействовать друг с другом.

Так же известен как “Обертка”.

Проблема

Чтобы продемонстрировать этот шаблон, я буду использовать упрощенный пример игровой механики, в которой есть интерфейс IEnemy, но один из врагов отличается от других и не имеет реализации метода атаки. Вместо этого этот конкретный враг (SpecialEnemy) накладывает заклинания.

Абстрактная фабрика - это шаблон проектирования, который позволяет создавать семейства связанных объектов без указания их конкретных классов.

Проблема

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

Семейство сопутствующих игровых вещей, например: chest + unit + hero.

Несколько игровых событий. Например, продукты Chest + Unit + Hero доступны в следующих ивентах: Pirate, Space, Default.

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

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

Решение

Первое, что предлагает шаблон «Абстрактная фабрика» - это явное объявление интерфейсов для каждого отдельного игрового предмета из ивента (например, сундук,  юнит или герой). Затем вы можете заставить все варианты предметов следовать этим интерфейсам. Например, все варианты сундуков могут реализовывать интерфейс Chest; все варианты юнитов могут реализовывать интерфейс Unit и так далее.

Следующим шагом будет объявление абстрактной фабрики - интерфейса со списком методов создания для всех предметов, входящих в ивент (например, createChest, createUnit и createHero). Эти методы должны возвращать абстрактные типы продуктов, представленные интерфейсами, которые мы извлекли ранее: Chest, Unit, Hero и так далее.

Фабричный метод - это творческий шаблон проектирования, который предоставляет интерфейс для создания объектов в родительском классе,  но позволяет подклассам изменять тип создаваемых объектов.

Проблема

Представьте, что вы создаете модуль игровых наград. Первая версия вашего приложения может обрабатывать только награду ЗОЛОТО, поэтому основная часть вашего кода находится внутри класса GoldReward.

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

Отличные новости, правда? А как насчет кода?

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

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

Всем приветы. Я работаю над игровым проектом. В нем потребовалось реализовать сундуки. Все кто играл в игры, сталкивались так или иначе с сундуками. Открывали их. Забирали выпавшие награды. А как это реализовано? Так как мне нужно было реализовать уже, в целом, не новую механику, я начал много спрашивать и искать подходящие варианты. Меня интересовало , буквально все. От возможности создания сервера, до того, как пользователь будет забирать награду. Возможно, я очень плохо искал и/или до сих пор плохо гуглю, но я не нашёл достаточно описания и разъяснения механик сундуков. Вы сталкивались с такими механиками? Как они реализованы у вас?

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

Окей, сундуки ушли на второй план. И нужно было определиться с тем как создавать награды, как хранить их в БД. Очень хотелось бы сделать достаточно гибкую систему, чтобы со временем была возможность добавить новые награды или выключить определенный тип наград. Первое что пришло в голову - сделать отдельную таблицу под каждую награду. Классная идея, под каждую таблицу есть свой репозиторий, достающий данные из БД, есть сервис обрабатывающий параметры награды и сервис по применению награды на игрока, когда он взял ее. И все работает отлично, пока не появляется необходимость собрать сундук из наград. Получается, что сущность Сундук, должна знать о всех наградах в системе. Добавление новой награды, вызывает изменение сущности сундук и сервисов, которые этот сундук открывают. Вообще это рабочий вариант, но принцип open-close говорит нам, что система должна быть открыта для расширения, но закрыта для изменения. 

   В прошлой статье мы разобрали, как писать сервер на gRPC. И протестировали его с помощью BloomRPC. Теперь, давайте разберем как пишется клиент. И попробуем отправлять запросы с клиента на сервер. Это будет наш первый шаг к созданию микросервисов на грпц. 

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

  Всем приветы. В прошлом посте https://habr.com/en/post/565020/ мы сравнили gRPC и REST. И собственно, прежде чем писать новый сервер на gRPC, давайте попробуем понять нужен ли он нам действительно. Нашей команде была необходима кодогенерация на разные языки программирования. На эту роль не плохо подходил Swagger, Thrift и gRPC со встроенным кодогенератором. От Thrift, спустя какое-то время, пришлось отказаться, из-за его особенностей и сложностей поддержи на c# (по-моему это была основная причина отказа). Дальше был выбор между Swagger + REST и gRPC. В целом оба варианта хороши, но если мы думаем гонять много и часто данные между клиентом и сервером, то почему бы не протестировать gRPC?  

Структура проекта будет выглядеть следующим образом.

Всем приветы. А вы писали новый сервер с нуля? Какие технологии использовали? А рассматривали какие-либо варианты кроме старого доброго REST ? А что есть еще что-то ? С такими вопросами я когда-то пришел к своему лиду.  Да, для меня было открытием, что можно использовать не только REST для обмена сообщениями между сервером и клиентом. Ах да, конечно я знал про SOAP, но использовать его уж очень не хотелось. Оказалось, что можно попробовать использовать Thrift или например gRPC. От Thrift пришлось отказаться по ряду причин, которые не сильно важны в данной статье. Кстати, возможно Thrift это именно то что вам нужно. 

Так что же такое gRPC и в чем его отличие от, уже ставшего классическим, REST? Лучше ли gRPC? Может gRPC это снова хипстерская технология, которую все скоро забудут?

   Не для кого ни секрет, что REST доминирует в современном мире API, особенно, когда речь идет о веб-приложениях и инфраструктурах, на основе микросервисов. Мало кто даже вспомнит, про то что микросервисы могут общаться по другому. Это наверное самый популярный ответ на собеседовании. Да если добавить еще feign клиента из Spring, то получается совсем красота и минимальные трудо затраты. Но для определенного набора сценариев использования, модель gRPC начала играть небольшую, но важную роль. Давайте попробуем разобраться, когда же нам стоит использовать REST, а когда gRPC.

Гитхаб экшены, как я познавал ci/cd

   Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd. 

   Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения. 

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

Алгоритм поиска строки Бойера — Мура — алгоритм общего назначения, предназначенный для поиска подстроки в строке.

Давайте попробуем найти вхождение подстроки в строку.