Как стать автором
Обновить

Мой тернистый путь в «Разработке Игр»

Время на прочтение15 мин
Количество просмотров9K

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

ВНИМАНИЕ! Дальше вас ждет простыня текста без юмора. Душнилово так же присутствует. Я не буду называть некоторые компании, в том числе и ту, в которой я работаю сейчас, чтобы, если меня понесёт, я не переписывал статью. Из песни слов не выкинешь. Позже, когда уволюсь, отредактирую добавив название компании. По тем же соображениям, чтобы не нарушать права на интеллектуальную собственность я не выкладываю куски кода, о которых пишу в статье. Опять же в будущем может быть добавлю.

Я сам люблю игры. Всегда интересовался разработкой игр. В детстве я посещал кружок программирования в местном Доме Детского Творчества. Там я написал первую игру ещё на БК-0010. Но это была не моя игра. Я скопировал чужой код. Так нас учили программировать. Хотелось написать, что мой путь программиста начался оттуда, но это не так. По настоящему заниматься программированием я стал только в 2015 году. До этого я скорее проявлял интерес к этому, при этом, в 2008 году, учясь в ВУЗе на кафедре Информационных технологий я посещал курс Программирования на C++. То есть тогда программированием я не грезил, а вот играми очень. И какой-то период времени плотно занимался моддингом игр (но в то время интернет был по карточкам, поэтому многие мои моды потерялись на поломанных жестких дисках старых компьютеров). Half-life, Max Payne, Quake, Doom, Unreal, Morrowind, Neverwinter Nights (и все продолжения этих игры в том числе) - только малая часть тех игр, над которыми я «издевался». Я делал карты и модельки оружий (отвратительного качества) на Counter-Strike. Поэтому желание состряпать свою игру у меня было всегда. Но были проблемы. Лень одна из них. Хотя она не мешала, это скорее больше влияло на то, что я каждый раз откладывал свой путь в «Разработку Игр». Типа «есть ещё время», «успею». И потому полноценно в разработку игр я влился только в 2020 году. В ковид от дикой скуки. До этого я продолжал заниматься экспериментами с модами, и тыкал в некоторые игровые движки. Но не было полноценных результатов, так как моды я не доводил до рабочего состояния, когда их можно было бы закинуть на тот же, известный среди модеров Nexus Mods. А игровые движки часто требовали серьезного изучения, чтобы получить первый вменяемый результат. То есть нужно было вкапываться в документацию и(или) в исходный код для понимания того, как начать в них что-то делать. Это сейчас даже raylib можно взять с наскока, так как порог входа на низком уровне, а в былые времена для того же Allegro требовались недели экспериментов, чтобы понять как и что работает. И часто именно «горящие глаза» энтузиазма не давали мне забросить работу над изучением очередного движка. К слову упомянуть, что в итоге я всё же забрасывал изучение, и полноценных знаний я не получал. Но получаемый опыт оседал в голове.

Как упоминалось выше, программированием я стал серьезно заниматься в 2015 году. Тогда я устроился на новую работу, где я по своему собственному желанию начал создавать программы. Это не было моей должностной обязанностью. Но подразумевалось по должности «Инженера автоматизации». Почему такое несоответствие требованиям я опишу ниже. В период работы на этой должности до 2020 года я более значимо для себя занимался поддержкой опенсорс проектов. Я контрибьютил в разные проекты, но важным для статья является один из них, который был форком проекта распознания лиц на видео для создания анимации YerFace. Сам форк уже в 2021 году сгинул. Автор форка из-за стагнации оригинального проекта в 2020 году не стал брать на себя ответственность за развитие, и я сам так и не понял почему он сделал форк, так как различий с оригинальным проектом было мало. Мне тогда казалось, что автор форка хотел развивать проект, поэтому я влился в него. А возможно он просто хотел скопировать готовый продукт и коммерциализировать его. Тут, я честно признаюсь, правды не знаю. Мой вклад в форк был мизерный, я интересовался больше областью распознавания лиц, нежели анимацией, так как на работе в то время я занимался проектом распознания людей по видео. Руководство компании, в которой я тогда работал хотело по видеонаблюдению видеть кто из работников где находится. И для этого создавалась система распознания. Именно из-за этого я влился в некоторые опенсорс проекты, чтобы увидеть как это реализуют другие. Но с анимацией я всё же имел дело, когда изучал код форка YerFace, и там была компьютерная графика.

В это время я плотно познакомился с OpenGL. Оказалось, что OpenGL не такой уж и сложный API (в ретроспективе можно уточнить, что по моему мнению OpenGL самый простой графический API из существующих). Я для себя тогда сделал замечание, что только моя лень раньше не давала мне прийти к написанию своей игры. Ничего не мешало. Проблемой был только я сам. И в 2020 году на волне опыта работы с OpenGL я взялся за написание своего игрового движка. Может показаться, что это уже сотни раз обмусоливали. И таких «амбициозных», как я, сотни. Тот же GitHub полон игровыми движками разной степени готовности. А уж сколько их в «столах» на домашних компьютерах можно только догадываться. И поэтому может показаться странным, что я не взял готовые решения, или не совсем законченые. Это же проще, с учётом моих же слов выше о лени. Возможно, но я сделаю уточнение. В том, что кто-то хочет написать свой движок нет ничего плохого. Наоборот, это может дать хороший буст знаний и опыта. Я уже тогда понимал, что это очень сложный проект. Я всё ещё хотел сделать игру. Но на пути к своей игре, я так же ставил цель набраться опыта разработки. Но не только игровых движков, а сложных проектов в общем смысле. Столкнуться так сказать с проблемами, которые помогли бы мне в понимании собственного уровня, как программиста. Это было связано с тем, что в тот период я работал в компании, где программисты были не разработчиками, а в большей степени поддержкой существующей кодовой базы. О несоответствии названии должности и должностных обязанностей я писал выше. И многие проекты были маленькими и локальными. И я по сути не занимался полноценной разработкой, только доработкой. У меня же было желание развиваться, чтобы не стагнировать. Поэтому и появился проект игрового движка с учётом его «сложности». И это дало свои плоды. Я с нуля разработал два программных продукта для внутренних нужд компании. Что для меня было серьёзным шагом вперёд. Но мои рабочие проекты к тому времени были уже никому не нужны. Под конец сотрудничества с той компанией в 2021 году произошли серьёзные изменения. Случился управленческий кризис. Руководство сменилось. И я принял решение менять работу. Оставаться на той уже было нельзя, если бы я хотел дальше развиваться, как программист. Руководству нужен был специалист поддержки проектов, и видело во мне именно этого специалиста. Стоит упомянуть, что этот социальный лифт тоже выглядел неплохо. Потому что дальше по должности руководитель отдела, подразделениями и там да заместителя директора недалеко. Но это хорошо выглядело только со стороны. Люди знакомые с работой в гос. учреждениях, или работавшие подрядчиками для них уже понимают, что я имею в виду. Поэтому оставаться там было бы ошибкой.

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

Спустя несколько месяцев поиска работы я вспомнил о том, что я всё же хочу сделать игру. Мысль о своей игре не оставляла меня долгое время. И поэтому я решил, что раз уж я всё равно ищу работу, то почему бы не пойти в разработку игр. До этого момента я вообще не рассматривал вакансии в компаниях разрабатывающих игры. Мне тогда казалось, что это не то чем я хотел заниматься. Так как разработка своей игры для меня была на уровне хобби. А сам я хотел заниматься разработкой прикладных программ с GUI в большей части. Мобильная разработка была в интересах, но на тот момент мой уровень в ней был невысок. И относительно провалов на собеседованиях по разработке для ПК, где меня рвали на части, в мобильной разработке я бы вообще был бы никем, в лучшем случае на уровне «вайтишника» с сертификатом за трехмесячный курс. Поэтому я начал искать вакансии уже конкретно в области разработки игр.

Мне не повезло. 2022 год начался «великолепно». Я именно в период начала СВО искал работу. И больша часть неудач можно, наверное, списать из-за этого. Рынок схлопнулся моментально. Я в режиме «реального времени» видел, как вакансии исчезают из агрегаторов. Вакансии для джунов исчезали самыми первыми. Была полноценная борьба за рабочие места. И я тогда чётко понял, что нужно быть более настырным. Браться за все тестовые задачи, каким бы они странными не были, так как это давало мне возможность увидеть свои слабые стороны, а значит я должен был эти места подтянуть. К примеру, одним из заданий было написать игру Арканоид за четыре часа. Такое задание мне выдали на собеседовании в Gaijin. Мне был представлен исходный код тестового движка. И я не справился. То есть что-то я написал, но полноценным арканоидом это не назвать. Можно ли написать полноценный арканоид за четыре часа? В теории можно, но только если уже такое делал ранее. А когда делаешь это впервые, да ещё и на движке который так же видишь впервые, то четыре часа это мало. Но я решил проверить свои силы. Можно было пойти другим путём, договорится об увеличении срока. Пошли бы на это с стороны рекрутеров? Я не знаю. Есть предположение, что врядли. Так как джунов много. Один не «справился» - найдётся другой.

Другим заданием было создать игру в Unity с определенной игровой механикой. С Unity я был знаком. Я уже не помню название компании, которая выдала это задание, но раньше, до собеседования, я видел это же задание в интернете, и даже видел в телеграм каналах по Unity вопросы о готовом решении этого задания. То есть я был не первый, либо просто разные компании хотели одного и того же - скопировать успешную игровую механику, под которую набирали команды. И в этот раз я то же не справился. Я не стал копировать те решения, которые я нашел в интернете. Я заданием проверял сам себя. Было ли правильным решение не копировать чужой код? Возможно нет. Так как, взяв чужое решение, поменяв кое-что, я мог бы уже тогда получить работу. Но всё же, получив работу, за меня будет её выполнять не другой человек, а я сам. Проверяя себя я пытался понять потяну ли. И понимал, что нужно свои силы рассчитывать. Проблема с этим заданием была в том, что задание я понимал буквально. В разговоре с рекрутером было оговорено, что нужно повторить игровую механику точь-в-точь. А повторить её так, как она выглядела на видео, которое мне предоставили, как референс, я не смог. Я честно написал, что выполнить задание не удалось. На этом общение в этим рекрутером сразу прекратилось. Что понятно, какой смысл тратить время на кандидата, который не справился. Я мог бы быть более настойчивым, что задание я выполнял, вот результат, но само общение мне понравилось, поэтому не стал продолжать.

Я после этого абзаца напишу ещё о собеседованиях в игровые компании подробнее, но вы не подумайте, что их было мало. Этим абзацем я немного отдохну и соберу мысли. Собеседований было много. Общее количество всех собеседований за всё время поиска работы переваливало за 100. То есть джунам всегда найти работу было сложно. Не невозможно, но много сложнее. Особенно тем, кто из глубинки ищет работу на удалёнке. Особенно в то время - начало СВО. И я читал советы, в которых описывали, что сто собеседований это ещё только начало. На некоторые позиции конкурс 1000:1, отсев дикий. И, например, в тот же Сбер в то время хотели попасть все. Там платили очень жирные деньги по меркам рынка того времени. И не пытаться туда попасть было бы глупо даже с учётом огромной конкуренции. Я пытался попасть в VK, Касперский, 2Гис, Авито. Список крупных IT-компаний был большим. Даже Яндекс фигурировал. И я пытался попасть в эти компании не сколько из-за денег (не в последнюю очередь) но из-за того, что там предлагали удалённую работу даже джунам. Это было не во всех подразделениях, но в некоторых. Для людей из глубинки это огромный плюс, так как желание связать свою жизнь с IT в таких местах разбивается о реальность, что нет вакансий. Чтобы найти работу нужно переезжать в крупный город, областной центр, столицу региона, либо искать удалёнку. Я же в тот период не мог переехать (не было денег), хотя ряд компаний готовы были меня взять на работу с условием моего переезда в город с их офисом. Поэтому я мог рассчитывать только на удалённую работу. Были и другие варианты. Но на тот момент для меня это было, фактически, как шаг назад, который я не хотел делать.

Третье запомнившееся собеседование в игровую компанию было в компанию Playrix. На нём я делал игру типа арканоида, но с немного другой механикой, больше похожей на механику игры Space Invaders. Игру удалось сделать, так как времени на выполнение дали достаточно (две недели). Но техническому специалисту не понравился результат, либо просто они уже к тому времени нашли подходящего кандидата, а мне просто не хотели резко отказывать, что то же понятно. Истинные причины для меня неизвестны. Я лишь получил обратную связь. И тут стоит упомянуть, что общение с рекрутерами Playrix было одно из самых адекватных и приятных за все собеседования, пройденные мной. Таким же по уровню было общение с VK. Но в VK я жёстко провалился, так как это было одно из первых собеседований. Я тогда ещё не умел правильно собеседоваться. О Playrix я ещё упомяну ниже.

Но не всегда всё шло гладко в общении. Например, компания Unigine вообще отказывала сразу без каких-либо этапов общения, а у них в вакансии был флеш рояль: джун, удалёнка и всякие плюшки. Упомянутая ранее компания Gaijin давала долгий ответ на вопрос уже после провала собеседования. Я хотел получить разрешение разместить скриншоты сделанной игры в портфолио. Ответ пришел спустя четыре дня, что упоминать о том, что это было задание на собеседование в компанию нельзя по соглашению. По какому соглашению я так и не понял. Так как я ничего не подписывал. Но раз уж их так заботило это, то я ни стал использовать готовый результат.

Последнее собеседование, после которого я получил работу я практически не помню. Помню только то, что я изначально его провалил, игру я делал на SFML, и то, что мне не давали обратную связь. Что за игру я делал я не помню. Даже исходников не нашёл, ни в переписке, ни в своих бекапах. Обратную связь я попросил самостоятельно отдельным письмом. Это один из самых важных моментов, правильный, я бы даже добавил - спрашивать рецензию за выполнение задание и обратную связь на пройденное собеседование. Ответ я получил быстро, но полученный ответ был фигней, практически отпиской. И к нему я написал, что советы, которые мне дали в обратной связи, хрень полнейшая, эти советы ничего мне не говорят, ни от том, как прошло собеседование, ни о том какие ошибки я совершил выполняя задание. После чего меня позвали на второе собеседование, где меня взяли на работу. Для меня это было удивлением. То ли моя прямолинейность и наглость взяла верх, то ли им отказал другой кандидат. Но всё прошло буквально за два дня. Это удивляет.

И тут стоит вернуться к моему желанию сделать игру. Свой движок я так и не дописал до сих пор. К времени последнего собеседования я третий раз пересоздавал репозиторий на GitHub с кодом своего игрового движка. Всё потому, что несколько раз рефакторил код движка, узнавая новые «методики» написания движков, которые я тут же хотел попробовать в своём. Из-за чего он становился всё более запутанным. И чтобы как-то привести его в нормальный читаемый вид, я удалял старый репозиторий и пересоздавал с новой структурой, чтобы на собеседовании можно было показать более менее рабочий вариант. И при этом, чтобы его старые варианты не мешали. И вы правильно заметите, что теряется суть контроля версий, что можно было бы создать отдельные ветки. Всё верно. Я тогда знал о git, мог им пользоваться, но не имел серьезного опыта работы с ним и его разными подходами к разработке в несколько веток. И потому не доконца понимал логику веток и их удобство. Сейчас всё иначе. Хотя я уже к fossil больше проникаюсь симпатией. Сейчас, поработав в большой команде я научился работать с большим, постоянно меняющимся кодом с кучей (около 30) веток.

Устроившись на новую работу я снова перестал работать над своим движком. Отложил его, потому что новая работа начала отнимать свободное время. Это было моё личное желание быстрее вкатиться в рабочие процессы и понимание того как всё в новой компании устроено. За тот период я понял, что оказывается я структурировал код своего движка нормально. То с чем я столкнулся было куда хуже. И я был поражён, так как компания существует не один год на рынке. Единой структуры в движке не было. Старые версии движка находились в той же папке исходного кода, что и текущий, никто не удалял его оттуда просто потому, что никто не понимал почему этот код находится там. Считалось, что если он там, то значит он кем-то используется. Только спустя время, когда начался рефакторинг кода и повсеместное использование git для версионирования, стало понятно, что старые версии кода никем не используются. Здесь стоит упомянуть Playrix, код движка которого ставили в пример. Я лично сам его в глаза не видел, но коллеги, которые работали в Playrix до текущего места работы отмечали, что движок Playrix очень хорошо структурирован и имеет удобную и подробную документацию. Уж простите, что раскрываю такие подробности. Но я считаю, что так должно быть везде. И мне [не] повезло работать с движком, у которого очень много пустых мест в документации, а та, что есть обновляется очень редко. У меня были задачи, где я как археолог или спелеолог спускался в глубь движка снимал слой за слоем абстракции для того, чтобы понимать, что вообще происходит. Так, например, я возненавидел директивы #define , которые в одном куске кода стреляли в ногу, но в совершенно случайный момент. Поэтому поймать эту проблему было невероятно тяжело. И что самое интересное. Визуально кусок кода показывал проблему, что падение должно было происходить каждый раз при выполнении этого кода. Но не происходило. И это как раз поражало больше всего. Будто оптимизации во время компиляции несколько меняли выполнение, что приводило к такому странному поведению.

То есть за время работы на текущем месте я получил большой опыт работы с плохим движком. То, как не нужно делать. И это с одной стороны хорошо. Опыт. С другой стороны - плохой код усложняет работу с ним. Очень серьёзно. И эта особенность сильно мешает выполнять задачи в короткие сроки. Некоторые задачи просто не возможно выполнять в сроки, которые хотят руководители. Это приводит к тому, что некоторые задачи выполняются плохо, ухудшая и без того плохой код. Растёт технический долг. Из-за чего растёт время выполнения задач. Но время на выполнение новых задач не увеличивают. Что приводит к ухудшению результата выполнения задачи. И так далее. Всё взаимосвязано. И это ещё только работа с кодом в движке. Становится [не] интереснее, если описывать работу, когда движок используется для создания продукта. Эта область может вообще никак не быть связана с движком. Так как в некоторых игровых движках взаимодействие с движком может происходить на уровне дополнительной абстракции в виде скриптового языка, который сам выполняет требуемое в продукте. И разработчики игры (гейм-дизайнеры) могут не понимать как работает движок. То есть движок выступает в роли черного ящика. И здесь может быть проблема, когда ошибка движка наложенная на ошибку в скрипте порождает конфликт интересов. Решить проблему на уровне движка нельзя, так как это может затронуть работу всех, растянет сроки выполнения задач. Решить проблему на уровне скрипта не хотят, так как раньше (год-два назад) этот же скрипт работал. Такое было в моей практике, и не раз.

Большая часть работы в игровой индустрии - банальная рутина, которая при отсутствии удобного инструментария может сильно портить желание ей заниматься, но понимая, что за эту рутину платят деньги, ей продолжают заниматься несмотря на «боль». Инструментарий это самое важное. В любой профессии. Хороший инструмент залог приятной работы. Но бывает так, что из инструментария только приложение «Блокнот» в Windows. С ним можно писать программы, но не очень удобно. Я только могу посочувствовать тем, кто занимается написанием скриптов для игр без удобного инструментария. Или, например, платформа Android. Её официальный инструментарий Android Studio. Для не просвещенных это один из самых конфликтных IDE с которым мне приходилось работать. Я читал о том, что XCode называют худшим, но для меня Пальму Первенства держит именно Android Studio. И это единственный IDE для системы Android. До недавнего времени был Visual Studio, но они свое решение пометили как deprecated.

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

Сейчас я уже не трачу свободное время на работу. Так можно делать только на старте карьеры, чтобы быстрее войти в работу на новом месте работы. Но никогда не проявляйте это перед руководством, так как хорошим это может не кончится. Выгорание это не пустые слова. Важно не терять интерес к работе, потому что это сильно скажется на вашей же производительности. Сейчас я трачу свободное время на разработку своих игр. Спустя столько лет. Здесь я сбрасываю рутину, и как раз получаю то веселье, которое не достаёт на работе. Я решил отложить разработку своего движка дальше во времени. Так как решил, что пока поизучаю другие движки (raylib, godot), чтобы понахватать в них интересных решений, чтобы можно было снова сесть и зарефракторить свой. Raylib, кстати, я очень рекомендую для использования тем, кто хочет написать свою игру, без использования больших игровых движков. Порог входа этой библиотеки относительно низкий, а большое количество существующих биндингов позволяет использовать её на разных языках программирования. Так же я начал изучать новые для себя языки программирования. Один из которых Zig. Я о нём пару статей выпустил здесь на Хабре. Занятный язык. На текущем месте работы я прокачался в kotlin. То есть даже в самых плохих ситуациях я получал опыт, чтобы он помогал в дальнейшем.

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

На этом всё. Спасибо, что дочитали

update:

Забыл написать о зарплатах. Чтобы было понимание. Относительно других областей IT зарплаты в разработке игр одни из самых низких. Считается, что разработка для микроконтроллеров самая низкая, но нет. В зависимости от времени, и от компании специалистам по микроконтроллерам платили хорошие деньги, а вот в разработке игр высоких зарплат никогда не было. Поэтому, если у вас имеется желание заработать звонку монету, то я рекомендую хорошо подумать о пути в разработку игр. И объясняется это просто. Во-первых, сама область не самая прибыльная. Есть исключения, но они единичные и в них нужно понимать почему они прибыльные. Во-вторых, поток «новобранцев» практически не скончаем. Желающих сделать игру очень много. А в текущее время с засилием «войтивайти» и инфоциган кандидатов стало ещё больше. Существует как раз нехватка специалистов высокого уровня, и рост их количества очень медленный, но вот джунов всегда было более, чем достаточно.

Теги:
Хабы:
Всего голосов 5: ↑3 и ↓2+1
Комментарии26

Публикации

Истории

Работа

Ближайшие события

One day offer от ВСК
Дата16 – 17 мая
Время09:00 – 18:00
Место
Онлайн
Конференция «Я.Железо»
Дата18 мая
Время14:00 – 23:59
Место
МоскваОнлайн
Антиконференция X5 Future Night
Дата30 мая
Время11:00 – 23:00
Место
Онлайн
Конференция «IT IS CONF 2024»
Дата20 июня
Время09:00 – 19:00
Место
Екатеринбург
Summer Merge
Дата28 – 30 июня
Время11:00
Место
Ульяновская область