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

Статья же призвана раскрыть определенную точку зрения на ведение переговоров для заключения контрактов с максимально выгодными для вашей компании условиями. За 14 лет эволюции от инженера первой категории до заместителя техдиректора по направлению внутренней и внешней инфраструктуры (а также консалтинга медиа-холдингов, стартапов, криптобирж и соцсетей) мне пришлось договориться о сотнях контрактов с контрагентами. Могу сказать, что подобный опыт применим везде — выбираете ли вы дата-центр, закупаете оборудование или ищите новый автомобиль. Как говорится: смелость города берет, а наглость и деревнями не брезгует.

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

И если в текстовом формате мы не первый раз рассказываем истории из разработки, то теперь решили организовать митап в сентябре вместе с друзьями из DevGAMM, где будем на реальных кейсах разбирать архитектуру в глобальном понимании — от системных решений и приложений до архитектурных паттернов и стилей. И в этот раз мы решили уйти от традиционного стиля «митапов», поэтому — всего 222 отобранных приглашенных, актуальные темы и крутой нетворкинг на митапе (А|а)рхитектура.

А для тех, кто заинтересовался — под катом FAQ и подробности.

— А мы покажем казуальный PvP-раннер с препятствиями для тех, кто любит унижения.
— Что?
— Что?

Перед одной из презентаций на PixJam Summer'18.

Зимой мы провели первый внутренний PixJam, в котором ребята из всех отделов креативили и придумывали концепты для новых игр (кстати, один из них уже готовится к софт-ланчу). Собрали тонну позитивных отзывов и фидбека, чтобы сделать его еще лучше, и повторили эксперимент. Расскажу, как он проходил на этот раз и что мы изменили.

Мы верим, что в каждом разработчике спит хороший рассказчик. Некоторые из них уже проснулись и радуют коллег классными постами. Остальных же нужно просто разбудить. Почему и кому нужно и как именно это сделать, мы обсуждали на РИТ++, где в рамках DevRelConf Хабр засветился сразу в двух активностях: мы провели творческую встречу с нашим издателем Денисом Крючковым и круглый стол о том, как вести профессиональные блоги.

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



Кстати, 23 августа у нас будет свой семинар о мотивации авторов, где мы, наши друзья из Microsoft, ABBYY, JUG.ru, Туту.ру, Badoo, Voximplant, RuVDS и один приглашенный эксперт подробно разберем кнуты, пряники и мотивационные таблетки, которые помогают превращать айтишников в хабраавторов.

В предыдущих статьях цикла (все ссылки в конце статьи) о разработке нового fast paced шутера мы рассмотрели механизмы основной архитектуры игровой логики, базирующейся на ECS, и особенности работы с шутером на клиенте, в частности, реализация системы предсказания локальных действий игрока для повышения отзывчивости игры. В этот раз подробнее остановимся на вопросах клиент-серверного взаимодействия в условиях плохого соединения мобильных сетей и способы повышения качества игры для конечного пользователя. Также вкратце опишу архитектуру игрового сервера.

Рассказывать о новых проектах это, конечно, хорошо, но не всегда всё получается, как мы хотим.

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

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

А вот внедряют аналитику все по-разному: кто-то покупает сторонние решения (просто, но негибко), кто-то пишет под себя (долго и дорого), а кто-то пока просто считает несколько базовых метрик силами программистов и не заморачивается.

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

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

В прошлой статье я описал технологии и подходы, которые мы используем при разработке нового мобильного fast paced шутера. Т.к. это была обзорная и даже поверхностная статья — сегодня я копну глубже и подробно расскажу, почему мы решили написать собственный ECS-фреймворк и не стали использовать существующие. Будут примеры кода и небольшой бонус в конце.

В мае вместе с CTO Pixonic Сергеем Ждановым (я — слева, он — справа) посетили Google I/O 2018 в Калифорнии. Хотелось посмотреть на тренды, технологии, пообщаться с разработчиками (я еще собирался поучаствовать в Codelabs, а то в прошлый раз не удалось туда попасть). В целом, если сравнивать с прошлым годом, Keynote был не такой впечатляющий, но все равно есть о чем рассказать по итогам конференции.

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

Год назад у нас в компании был один проект — мобильный шутер War Robots с относительно медленными, но красочными и напряженными боями. Игра продолжает развиваться, у нее десятки миллионов установок и игроков по всему миру, постоянно выходят апдейты. В какой-то момент мы захотели сделать динамичный шутер на Unity со скоростями, сравнимыми с Overwatch, CS:GO или Quake. Но реализовать задуманное для мобильных платформ (в первую очередь iOS и Android) на основе War Robots при текущих архитектуре и подходах было практически нереально.

Мы понимали, как это сделать в теории — есть много статей, презентаций на YouTube, детально рассказывающих о том, как написать шутер, как работать с сетью, какие возникают проблемы и как их решать. Здесь нет Rocket Science, все эти подходы придумали еще 30 лет назад и за это время они особо не поменялись. НО: у нас не было практики.

Забегая вперед, скажу — нам удалось реализовать задуманное. Мы создали для мобильных платформ динамичный быстрый шутер, который сейчас находится в бета-тестировании и активно дорабатывается. И мне очень хотелось бы всем этим поделиться. Это первая, обзорная статья с перечислением и кратким описанием практически всего того, что мы используем (прошу не путать с другим нашим проектом в разработке, технологии и подходы в котором похожие, но отличаются в деталях).

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

Нам, например, круглосуточно требуется мониторить более 46 000 метрик на более чем 500 серверах в 6 дата-центрах и 4 странах, а DAU игры War Robots стабильно переваливает за 1 500 000 человек.

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

У нас в компании для организации и управления доступами для Linux-серверов
используется такой сервис как FreeIPA. FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL. В новой версии появились уровни доменов и был переработан процесс настройки репликации. Так как инструкций вменяемого вида в рунете найти не удалось, я решил написать собственную.

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

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

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

Много раз я пытался объяснить своим знакомым, чем занимаюсь. Обычно я обзываю себя специалистом по связям с общественностью. По крайней мере, это более или менее понятно. Но когда аналогичный вопрос задают люди из игровой индустрии — это настораживает. «Как же так, — подумает комьюнити-менеджер. — Есть же игроки, нужно сделать социальную среду — неужели вам этого недостаточно?». Возможно огорчу кого-то из коллег, но, нет, недостаточно. Когда к вам обращается основатель инди-студии и спрашивает, зачем же нужны КМ, аксиомы вроде «услышанный игрок = счастливый игрок» не убедят его тратить и без того ограниченный бюджет.

Не только в России, но и за рубежом, я все чаще натыкаюсь на обсуждения ценности и обязанностей таких сотрудников: «Кто эти люди, чем они занимаются, в чем их польза, а главное — как подсчитать эту пользу?». Так что давайте уже разбираться — нужен ли кому-нибудь комьюнити-менеджер…

Жаль вас расстраивать, коллеги, но мой ответ: никак. Или, как говорилось в одной отечественной рекламе, «сынок, это фантастика». Нет, в природе существуют Tier IV ДЦ и ЦОДы, заключающие и выполняющие SLA, но в этой статье речь пойдет не о них (так как их услуги стоят, простите за каламбур, заоблачных денег), а о провайдерах выделенных физических и виртуальных серверов и сервисов, которыми в настоящее время пользуется большинство простых смертных, в том числе и мы в Pixonic.

Я намеренно не буду приводить названия конкретных компаний, с которыми мне приходилось работать как в Pixonic, так и до него, чтобы донести уже озвученную идею: так или иначе, серьезные «нюансы» обнаруживаются у всех. Возможно, кто-то захочет поспорить, но мое заключение основывается на более чем 8-летнем опыте общения с техподдержкой и менеджментом дата-центров разного уровня по всему миру.

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

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

Оптимизация проектов для виртуальной реальности требует своего особенного подхода. Помимо общих вещей, на которые следует обращать внимание при разработке 3D-игр, VR накладывает ряд строгих ограничений. От любого приложения требуется не только практически мгновенный отклик на любое движение игрока (будь то поворот головы или взмах руки), но и обеспечение стабильной частоты кадров, намного превышающей стандартные требования к «классическим» играм любого жанра.

Современные шлемы, такие как Oculus Rift и HTC Vive, поддерживают ряд специальных технологий, которые призваны сглаживать падения производительности. Это должно позволить компенсировать проседания FPS, искусственно повышая частоту кадров; улучшить пользовательский опыт; предоставить немного дополнительной свободы разработчикам конечных продуктов и снизить минимальные системные требования. Но так ли прекрасно все оказывается на практике? Как работают эти технологии и в чем между ними разница? Об этом и пойдет речь в настоящей статье.

На WWDC’17 Apple показала обновленный интерфейс App Store и представила ряд нововведений. Среди них были продвигаемые встроенные покупки, которые с выходом iOS 11 будут выводится прямо в поиске и редакторских подборках наряду с приложениями.

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

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

Содержание:

1. FreeIPA агенте в lxc контейнерах
2. Библиотека для использования API в python
3. Несколько слов про Ansible модули
4. FreeIPA агент в debian
5. Реплика в Амазоне