Это история из цикла «как войти в IT», написанная старпером, ветераном броуновского движения, который помнит динозавров. Поэтому его опыт вхождения в ИТ никому не пригодится, но представляет интерес с точки зрения истории.  

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

К написанию данного текста меня подтолкнула беседа с одним из крутых разрабов из «жирной» конторы, с которым мы пересеклись на яхте в Средиземном море. Узнав, что я тоже из Бауманки, и у меня свой бизнес, он заинтересовался и выспрашивал. Как я смог начать бизнес на софте, почему не пошел в большую контору, типа Yandex, Сбер и прочие. У него тоже знакомство с софтом началось как создание собственной разработки по анализу результатов металлургических испытаний в лаборатории, но закончилось работой прогером по найму. Попивая вино на яхте где-то между Турцией и Грецией в 2023 году, он предположил, что, возможно, если бы он продолжал писать софт для металлургических исследований, то, наверное, сейчас мог плавать на своей яхте, а не арендованной, и не около Турции, а на Карибах (но это не точно). А поскольку фарш невозможно провернуть назад, я решил описать свою историю успеха, так как она забавна и поучительна.

TL;DR написал актуальную на момент августа 2023 года заметку про необходимых для нормального администрирования групп ботов. Желательно бесплатных.

Сегодня я хочу рассказать про особый вид треугольников, впервые рассмотренный советским математиком Игорем Федоровичем Шарыгиным. Удивительно, что до ХХ века никто так и не обратил внимание на этот бриллиант.

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

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

С лишним весом я на ты. Со 115 кг я «сбросился» до 72, затем в течение 3-х лет вернулся обратно к 94-м, а сейчас опять худею (уже грамотно) и в данный момент вешу 88.7 кг (ещё 7 скину и остановлюсь). Таких историй много, поэтому об этом я не буду, а вот причины (биологические и поведенческие), по которым вы можете не худеть, не видел, чтобы кто-то описывал в полном объёме и понятным языком. Сегодня я постараюсь сделать это для вас, обобщив все свои знания о лишнем весе. 

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

Привет, хабр! С удивлением обнаружил, что здесь нет ни одного упоминания Grafana OnCall, Incident Response Tool с открытым исходным кодом от Grafana Labs. И это нужно исправлять, ведь мы бурно растем как по звездочкам на гитхабе, так и как часть Grafana Cloud, а в issues на гитхабе, в основном, встречаются техлиды из FAANG.

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

Нижеприведенный список является моей небольшой коллекцией примеров кода на языке С, которые не являются корректными с точки зрения языка С++ или имеют какое-то специфичное именно для языка С поведение. (Именно в эту сторону: С код, являющийся некорректным с точки зрения С++.)

Этот материал я уже публиковал на другом ресурсе в менее причесанном виде, Я бы, наверное, поддался прокрастинации и никогда не собрался опубликовать эту коллекцию здесь, но из-за горизонта уже доносится стук копыт неумолимо приближающегося С23, который безжалостно принесет некоторые жемчужины моей коллекции в жертву богам С-С++ совместимости. Поэтому мне и пришлось встать с печи, пока они еще актуальны...

Разумеется, язык С имеет много существенных отличий от языка С++, т.е. не составит никакого труда привести примеры несовместимостей, основанные, скажем, на ключевых словах или других очевидных эксклюзивных свойствах С99. Таких примеров вы не найдете в списке ниже. Мой основной критерий для включения примеров в этот список заключался именно в том, что пример кода должен выглядеть на первый взгляд достаточно "невинно" для С++-наблюдателя, т.е. не содержать бросающихся в глаза С-эксклюзивов, но тем не менее являться специфичным именно для языка С.

Всем привет, меня зовут Вячеслав Зотов, я аналитик в студии Whalekit. В этом тексте я расскажу про статистические тесты и сравнение воронок, а также мы попробуем разобраться, что объединяет χ²-тесты, какова область их применения и подробно исследуем применимость χ²-тестов к анализу воронок. И все это с примерами на Python.

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

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

Эта статья написана по мотивам одноименного доклада, с которым я и моя сестра Алина выступали на конференции Talents in Games в декабре 2021 года. Я — дизайнер, сестра — разработчик, и уже четвертый год мы работаем в одной продуктовой команде. Сейчас наши команды хорошо ладят и научились решать конфликты, но путь к взаимопониманию и здоровым отношениям между дизайнерами и разработчиками для нас был непростым и довольно долгим.

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

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

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

Мне всегда хотелось иметь возможность отлаживать bash-scripts так же, как и любой другой код, т.е. по шагам, и bash такую возможность предусмотрел, но о ней не все знают. Несмотря на довольно большой опыт использования Linux, я дошёл до неё только недавно.

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

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

Однажды, если мне не изменяет память, в Нью-Йоркском университете кто-то сформулировал определение геймдизайна как «мотивирование игрока на определенные действия». Хорошая формулировка. По аналогии с ней, про левел-дизайн я бы сказал так:

Левел-дизайн — это мотивирование игрока на определенные действия через окружение, в котором существует управляемый персонаж. 

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

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

Откуда возникла эта ниша? Что левел-дизайнер отдаёт в результате работы над локациями? В этом мы и будем разбираться дальше в этой статье. А вообще их будет целый цикл, в котором я постараюсь охватить всю базу этой области геймдизайна от самых основ до приемов AAA-сегмента.

Привет! Меня зовут Денис Рычковский. Всю сознательную жизнь я люблю две вещи: арт и игры. С 2015 года я работаю в геймдев-индустрии, а последние 3,5 года — на позициях лида и арт-директора.

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