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

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

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

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

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

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

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

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

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

Месяц назад Apple предупредила всех разработчиков, что с апреля все приложения, которые заливаются в App Store, должны быть собраны с использованием последнего iOS 11 SDK. О том, как правильно позиционировать контент, используя новый API, уже давно можно почитать в официальной документации и Human Interface Guidelines. А хорошими и подробными статьями об адаптации игр на Unity ни на русском, ни на английском языке нас не радуют. А так как в War Robots поддержка нового UI появилась с февральским релизом версии 3.6.0, я решил написать собственный гайд со скриптами и скриншотами.

Появилась необходимость сменить основной домен компании в G Suite с .ru на .com с сохранением всех данных, календарей, псевдонимов и доступов на сторонние ресурсы. Информации о переезде в интернете не очень много, а точнее, кроме справки самого Google, вообще ничего не нашлось, что и стало причиной создания этого how-to. Будет полезно, если кто-то решит повторить подобное.

Дело в том, что изначально в компании использовался домен pixonic.ru. Затем был добавлен псевдоним pixonic.com, но везде по умолчанию стояла почта в зоне .ru. А так как многие сотрудники компании ведут переписку с зарубежными коллегами и клиентами, было желание использовать международный формат. Для этого им приходилось заходить в настройки аккаунта, самостоятельно менять основной почтовый адрес и приводить подпись в соответствие с корпоративным шаблоном. Не все это делали (или делали, но через раз) и можно представить, какой беспорядок и путаница творились в ветках сообщений. Для внешних партнеров это выглядело еще менее презентабельно из-за разных подписей.

В общем, настал момент, когда было решено — вся переписка должна вестись с использованием почты pixonic.com. Задача упала на нас — системных администраторов.

В конце статьи есть ссылка на весь скрипт, поэтому в тексте будут лишь его куски.

— А у тебя какая идея игры?
— Хочу, чтобы все офигели, передать ощущение скорости, которая нарастает, пока у тебя мясо от костей не начнёт отлетать, и ты уже не понимаешь, сможешь ли с ней совладать, но все равно продолжаешь пушить как сумасшедший!
— Матч-3 что ли?
— Ага.

Из разговоров на PixJam.

Провели внутри компании первый Jam по созданию концепций новых игр и хотим поделиться впечатлениями. Идея заключалась в том, чтобы раздвинуть рамки и «заразить» креативом как можно больше сотрудников (в независимости от скилла в программировании или гейм-дизайне). Идея провести подобное мероприятие в формате Jam'a возникла у Игоря Клюкина — нашего СОО. Как показывает практика, такой формат в целом хорошо подходит для решения креативных задач.

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

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

Пару лет назад мы располагались в самом cost-effective (читай: «дешевом») дата-центре в Германии. Чтобы вы понимали условия — роутинг мог сбоить от стойки к стойке или внутри неё; свитч в стойке перегружался или зависал; сам дата-центр постоянно ддосили; жесткие диски выходили из строя; материнские платы и сетевые карты сгорали; сервера произвольно выключались, перезагружались, а сетевые кабели выпадали как осенние листья во время урагана.

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

Наступила точка кипения и мы решили переезжать. Хотя в какой-то момент даже казалось, что дешевле нанять больше обслуживающего персонала, чтобы менеджерить ситуации в вышеупомянутом ДЦ. Но в итоге, чтобы «стало более лучше жить» — мы выбрали стабильность.
Выбор остановился на дата-центре в Голландии, в Амстердаме. А вот тут самое интересное: к тому времени у игры уже был приличный DAU, переезд нужно было осуществить онлайн, без даунтаймов, одновременно на обе платформы (Android и iOS). Мало того, мы получили фичеринг на Google Play, маркетинг еще и запустил рекламную кампанию. Как понимаете, дополнительного трафика стало очень и очень много.

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

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

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

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

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

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

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

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

Содержание:

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

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

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

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

Напомню, кластер будет размещаться на площадке хостера, логи будут собираться со всего мира по TCP, а среднее количество логов — около 1,2 Тб/день при нормальных условиях.

В настоящее время мы используем CentOS 7 и Graylog 2.2, поэтому все конфигурации и опции будут описываться исключительно для этих версий (в Graylog 2.2 и Graylog 2.3 ряд опций отличается).

Несколько лет назад появился прототип игры War Robots (тогда она еще называлась Walking War Robots). Это был первый опыт Pixonic в жанре тактического PvP, поэтому многие будущие проблемы были заложены в коде изначально. Но несмотря на ряд трудностей (популярность проекта стремительно росла, небольшая команда не могла полностью изменить архитектуру игры в краткие сроки), нам в итоге удалось свести к минимуму количество читеров, а также исправить другие недостатки оригинального кода. Расскажу немного подробнее.

В марте 2017 года мы собрали небольшую команду и взялись за разработку нового перспективного проекта. Без особых деталей могу сказать, что задача стояла интересная и соблазнительная — мобильный, синхронный, командный PvP. Спустя 7 месяцев активной разработки мне захотелось рассказать коллегам из других проектов и отделов Pixonic технические детали и я подготовил для них презентацию, которая в дальнейшем превратилась в эту статью.

Как техлид команды, я расскажу, с какими задачами и проблемами мы успели столкнуться, как их решаем и почему. Мы используем итеративный подход добавления функционала в проект и в данный момент у нас реализованы: PvP на iOS и Android (обе платформы играют на одних серверах); набор персонажей, три десятка игровых механик, боты; матчмейкинг; набор мета-фич (кастомизация персонажей, прокачка и другие); решена задача масштабируемости на весь мир.

Итак, поехали.

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

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

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.

HackerRank в этом месяце предоставили интересную аналитику на основе опроса 39 441 разработчика. В опросе поднимается много актуальных вопросов про состояние IT-рынка, востребованные качества среди разработчиков и то, что ищут программисты среди потенциальных работодателей. Отчет получился интересным, многим может быть полезно.

Под катом очень много картинок.

1. Пролог

Hello world

В будущем то, как мы все работаем, изменится. Кем бы вы ни работали, для каждого важно научиться программированию, ведь именно оно развивает вычислительное мышление (или computational thinking), которое играет важную роль в принятии решений. Обычные резюме уйдут в прошлое и на первый план в вопросах найма новых сотрудников выйдут именно их умения.

Мы запустили HackerRank в конце 2012, чтобы помогать разработчикам найти работу, которая будет им по душе. За эти годы мы сильно выросли — сейчас в нашем сообществе 3,2 млн человек и 2% всех новых наймов разработчиков в прошлом году были сделаны с нашей помощью.

И сейчас мы впервые провели опрос среди нашего сообщества разработчиков, чтобы разобраться в том, как именно они работают и как они этому научились: когда они впервые запушили код в репозиторий, как они научились кодить, расспросили о любимых языках программирования и фреймворках, узнали, чего они хотят от работодателей. А еще мы спросили HR-менеджеров о том, что именно они ищут в кандидатах на позиции разработчиков и о многом другом. Мы опросили 39 441 человека и готовы поделиться знаниями, которые получили в результате.

Вы знали, что 1 из 4 разработчиков научился кодить до того, как получил водительские права?

Надеемся, что наш доклад будет для вас полезным.

Вивек Равинскар, Co-founder/CEO HackerRank