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

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

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

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

Обо всем этом — читайте ниже.

От модов до информационной безопасности

Как и многие, игры я люблю с детства. Но в какой-то момент я понял, что люблю не только играть в игры, но и их делать. И таким моментом я считаю свои школьные годы, когда я впервые пробовал ковыряться в редакторах Morrowind и WarCraft III. На полную все раскрутилось в универе, когда вышел Fallout 3 и редактор к нему. Я тогда изучил всю его документацию — что было не так-то просто, ведь она была на английском, а познания мои в нем оставляли желать лучшего. Тогда я сделал достаточно известный квестовый мод для Fallout 3 — «Убежище 74». А после него и другие.

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

Но тогда моды были скорее как хобби, а ведь еще были учеба, работа. Я отучился на специалиста по информационной безопасности и пошел работать по специальности в РКК «Энергия» (которым принадлежит космодром «Байконур» — именно они запустили первый искусственный спутник земли). Ревьюил там документацию несколько лет, и чем дольше этим занимался, тем больше приходил к пониманию, что это не то, в чем я хотел бы развиваться. Стал думать, чем заняться по жизни, искать себя. В какой-то момент как будто посмотрел на себя со стороны — что мне нравится: читаю про игры и геймдев, играю в игры, делаю моды. Долгое время почему-то мне даже в голову не приходило, что заниматься разработкой игр по-серьезному — а что, так можно было?

Стал анализировать в какое направление податься, и понял, что больше всего тяготею к геймдизайну и левел-дизайну в частности. Прочитал кучу статей про то, что нужно знать и уметь для работы левел-дизом. Понял, что мне понадобится хорошее портфолио и навыки работы с современным софтом и редакторами. Начал с 3ds Max в свободное время, после работы. Быстро понял, что времени по вечерам и выходным мне категорически не хватает, и стал откладывать деньги, чтобы уволиться и фулл-тайм заниматься портфолио. Где-то спустя полгода так и сделал. 

За несколько месяцев я собрал себе хорошее портфолио с примерами работ на Unity, Unreal Engine и CryEngine. Стал откликаться на вакансии, писать на почту в разные известные мне компании. Месяца полтора я безрезультатно рассылал резюме, пока в конце ноября 2016 года не получил пару ответов, а уже в начале декабря не открылась новая вакансия левел-дизайнера в Pixonic. Тогда я понятия не имел, кто это такие, но написал хорошее сопроводительное письмо, в котором по пунктам расписал, почему я идеально подхожу на конкретную вакансию, и приложил портфолио. На следующий день позвонили и позвали собеседование. В результате я имел на руках три оффера, но быстрее всех предложили выйти на работу именно в Pixonic, спросив лишь только, нужен мне MacBook или стационарный ПК. 

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

Я стал активно погружаться в левел-дизайн: сначала на основном проекте — War Robots, затем на экспериментальном  VR-проекте. Постепенно ко мне стали обращаться по всем вопросам, касающимся левел-дизайна, и меня сделали лидом этого направления. 

Спустя некоторое время мне предложили возможность взять на себя часть геймдизайна, в добавок к левел-дизайну. Некоторое время я колебался, но все же согласился. Спустя еще время стал единственным лид-ГД на War Robots, а спустя три года — и руководителем всего направления геймдизайна в компании.

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

Я закончил СПБГУТ им. Бонч-Бруевича по специализации «Программирование и автоматизация вычислительной техники» — и, по идее, если бы я пошел работать по своему профилю, то писал бы драйвера для Wi-Fi-роутеров и коммутаторов или же разрабатывал онлайн-мессенджеры вроде Skype и Zoom. 

Но после окончания ВУЗа в конце 2015 года передо мной встал вопрос о прохождении срочной службы в ВС РФ. И так как у меня было высшее техническое образование, мне предложили пойти служить в научную роту Военной академии связи в Санкт-Петербурге. Уже там мне сказали, что для службы необходимо изучить Unity и C#, ведь игровые движки отлично подходят для симуляции военных действий и создания тактических задач: как разместить танки, где окопаться, где прорыть линии связи, как провести логистику и прочее, и прочее. Раньше офицеры рисовали все это карандашом на распечатанных черно-белых картах, а теперь то же самое можно было делать как в компьютерной игре. Так что весь год срочной службы я разрабатывал прототип такого симулятора.

Надо сказать, C# в универе я не изучал — там у нас был C/C++ и немного ассемблера. Я изучал самостоятельно Java, а C# после него освоить было уже довольно легко. К тому же, мне не было нужды глубоко копать этот язык, а стандартные команды в разных языках программирования очень похожи.

Собственно, после службы я в геймдев и попал — свою первую работу в индустрии нашел в марте 2017. Я устроился в компанию ArPoint, занимающейся приложениями с AR/VR технологиями. Там в основном писал демонстрационные приложения — что-то вроде такого:

В конце того же года перешел в RuSoft, где занимался уже браузерными играми. Спустя год компания закрылась, и я начал работать в стартапе, где мы делали мобильные игры. А с сентября 2019 года — в BeinGame, которая затем стала частью Nord.

Как мне кажется, игровая разработка следует принципу “Easy to learn, hard to master”. Чтобы попробовать себя в этой сфере, не нужно тратить пять лет обучения — стоит просто написать первую игру или сделать первую 3D-модель и понять, твое ли это. В Интернете достаточно обучающих материалов, платных и бесплатных курсов, чтобы ознакомиться с азами. Разумеется, если вы захотите мощного карьерного роста, придется много работать, много учиться и постоянно развиваться. Но если вы к этому готовы — я думаю, что все у вас получится, ведь хорошие специалисты здесь нужны всегда.

Даже если у вас все трудно с программированием, геймдев, как и IT в целом — это не только про код: есть много смежных интересных профессий. Геймдизайнеры не пишут код, но продумывают баланс игры, меняют настройки, анализируют поведение игроков и решают, куда и как развивать проект. Художники рисуют несчетное количество красивых картинок, иконок, кнопок и других элементов пользовательского интерфейса. Есть 3D-моделлеры, которые делают модели персонажей и окружения. Есть специалисты по анимациям, освещению в игре, звуковики и так далее. Думаю, что тут каждый человек, который не просто любит игры, но хочет и готов работать в геймдеве, найдет себе что-то по душе.

О том, как тяжелые времена способствуют переменам

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

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

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

Время шло, жизнь становилось более «взрослой», появилось больше ответственности. Я уже работал инженером по тестированию, на дорогу до работы тратил примерно 3,5 часа в день, и времени на игры совсем не оставалось — хорошо, если удавалось поиграть часок вечером или найти время на выходных. Так как играть сам я не мог, я стал смотреть летсплеи и даже пробовал их снимать, а в процессе разобрался с видеомонтажом, графическими редакторами. Дело кропотливое и творческое — я бы даже сказал, медитативное.

Спустя 4 года работы в моей первой компании, из которых два года я проработал тестировщиком и еще два — разработчиком, я получил интересный оффер на работу в Германии, в автомотив, а точнее — в компании Luxoft над проектами Mercedes. После переезда туда с играми пришлось почти что полностью завязать сразу по ряду причин. Во-первых, из-за таможенных ограничений очень сложно было перевезти свой игровой компьютер из Москвы в Берлин, поэтому играть было банально не на чем: из техники у меня с собой был полудохлый ноутбук и телефон. Во-вторых, начинать новую жизнь в «чужой», незнакомой стране требует много сил, времени, нервов, денег и прочих ресурсов. Поэтому месяца три мне было просто физически не до этого. 

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

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

И вот спустя 1,5-2 месяца поисков я получаю и принимаю оффер, о котором еще ни разу не пожалел. 

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

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

Про завод и любовь к «Аллодам»

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

Но игрушки игрушками, а после школы надо было выбирать, что делать дальше. На тот момент у меня не было ни малейшей мысли о геймдеве и что в него можно как-то попасть. И я пошел учиться в МГТУ имени Баумана на инженера-технолога машиностроения.

Я тогда мыслил понятными мне и окружающим категориями. Вот я отучился 6 лет на инженера, так что иду работать инженером на завод. Устроился на военно-промышленное предприятие в Реутове, где занимался технологией изготовления космических спутников, ракет-носителей и крылатых ракет для подводных лодок. Огромные ангары со сборочными цехами, многоэтажные испытательные установки, военная охрана, люди в касках и белых халатах — звучит и выглядит это очень интересно, но я так и не проникся. И чем дольше я там работал, тем больше росло понимание, что такая деятельность мне совсем не интересна — хотелось чего-то совершенно другого.  

Выбрать дальнейший путь мне помогла любовь к играм. На тот момент я много играл в «Аллоды Онлайн», нашу отечественную MMORPG — авторства, кстати, почти одноименной студии, моих нынешних коллег по MY.GAMES. Так интересно замкнулся круг. 

Однажды разработчики устроили конкурс среди игроков: нужно было написать дизайн-документ будущей локации, и лучшую работу обещали реализовать в игре. Такой приз меня очень замотивировал. А дальше — произошло чудо: мою локацию признали лучшей и добавили в игру. 

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

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

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

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

Так однажды я написал и в Pixonic. Мне выслали тестовое на должность левел-дизайнера: нужно было спроектировать уровень для PvP-шутера. Какие-то знания о левел-дизайне у меня уже были с курсов и из тематических статей, так что с заданием я справился и попал на собеседование. У меня это было уже не первое собеседование в геймдеве, так что оно прошло довольно гладко, и меня взяли на работу. 

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

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

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

Опять же, очень рекомендую геймджемы как отличный мотиватор не только собрать законченный прототип игры в короткий срок, но и получить по нему отзывы от других участников. Гейм-джемы отчасти помогут вам понять, подойдет ли вам работа в крупной компании, когда у каждого сотрудника есть определенный набор обязанностей, или же вам настолько понравится дух инди и самостоятельной разработки, что ваш прототип перерастет в релиз полноценной игры. А что? Среди известных игр есть примеры, выросшие из гейм-джемов: например, SUPERHOT или Hollow Knight.

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

Из ОТК телеканала — в тестирование игр

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

Сменить сферу деятельности мне посоветовал тогда еще муж, хотя он сам к геймдеву не имел никакого отношения, но активно играл на ПК. Сама я тоже играла с детства: в основном это были рабочие компьютеры родственников с какими-то играми, запускавшимися из-под DOS, затем — уже в школе после уроков информатики. Естественно, игры мне нравились, но все-таки как потребителю: максимальным приближением к их разработке был редактор карт Heroes of Might & Magic III, и то дальше его запуска я особо не заходила.

Мой заход в геймдев в то время был больше похож на что-то вроде «упал, очнулся, гипс»: подготовка к написанию резюме и собеседованию состояла в основном из чтения Википедии про тестирование и прохождения самой приятной для меня по арту на тот момент игры студии — Whalekit, той же, где я работаю вот уже 9 лет. 

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

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

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

Железные дороги и фотографии для памятников — нескучные приключения иностранца в России

Я родился в Латвии, там и жил до 19 лет. Выучился на специалиста по железнодорожной безопасности и планировал работать по специальности. Всю жизнь я увлекался играми: всегда старался следить за новинками, пробовать разные жанры — в общем, не загонял себя в рамки любви к одной серии/жанру/типу игр, а поглощал все, до чего мог дотянуться. О работе в геймдеве особо и не думал: для меня это было что-то далекое и чересчур фантастическое.

В какой-то момент я решил уехать пожить в Россию, в Брянск, к своей будущей жене, с которой, кстати, когда-то познакомился в онлайн-игре. Переехал, пожил, женился, решил остаться. Устроиться в РЖД возможности не было, так что я начал искать работу вне сферы, в которой хоть что-то понимал. Забавные были времена: тогда я успел поработать и грузчиком, и в колл-центре службы доставки, но в итоге попал в багетную мастерскую-фотостудию, где работал фотографом и Photoshop-мастером. Кстати, так вышло, что со студией рядом было бюро похоронных услуг, а потому мне часто приходили заказы на подготовку фото для похорон и на надгробный камень. Теперь я иногда шучу, что до геймдева работал с покойниками, да простят меня читатели.

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

Я начал в срочном порядке думать, в какую сферу теперь пойти, ведь под угрозой оказалось мое само нахождение в России: безработные иностранцы никому не нужны. Искал, пробовал, собеседовался в разные места, пока однажды жена не сообщила, что открыта вакансия на младшего QA-специалиста у нее в компании. Тогда еще не было толком никаких обучающих курсов, но у меня под рукой был личный QA, который поднатаскал меня. В итоге я прошел собеседование — и так попал в геймдев. 

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

Со временем мы с женой перебрались в Москву — там был офис WebGames, которые, в свою очередь, владели Drimmi, и я продолжил работать уже как геймдизайнер там. Спустя еще несколько лет в меня поверил старый знакомый и предложил поработать над чем-то более крупным — над игрой War Robots. Для меня это было что-то запредельно крутое. Игра про огромных роботов, на мобильной платформе, PvP-ориентированный шутер — совершенно новое поле для творчества и развития. 

Правда, с первого раза устроиться в Pixonic я не смог: я был не готов, мне не хватало технической подкованности, да и проект, над которым я работал в WebGames, бросать не хотелось. В любом случае, случилось самое главное — я получил полезный фидбек и знал, что от меня требуется. А фидбек был примерно следующего смысла: «Ты, Эрик, с Unity не работал, а у нас все на Unity. Надо обучиться работе в Unity». Меня готовы были натаскать и на месте, но все же я предпочел работать над прежним проектом и в то же время оттачивать техничку: скачал себе движок, начал учиться по материалам из Интернета. Вдобавок, новые проекты WebGames тоже начали делать уже на Unity, так что удалось набить руку и там.

Так вышло, что спустя год мой проект был заморожен, и хотя работы было достаточно и на других проектах WebGames, я решил еще разок попробовать устроиться в Pixonic. И знаете что? Получилось! Я стал геймдизайнером здесь. Ну а далее, за годы работы с крутыми спецами на War Robots, я прокачался до старшего, а в последствии и ведущего геймдизайнера. Такая вот история.

Переобувка из журналиста в геймдизайнеры и борьба с цифрами

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

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

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

После этого тестового я, видимо, попал в резерв — это были BIT.GAMES, которые в итоге где-то через полгода меня позвали к себе на работу. Первые пару лет я постоянно овертаймил, но даже это было в кайф. Все вокруг были такие мотивированные, влюбленные в работу, активные — в общем, полная противоположность предыдущим работам. В команду я тогда попал очень компактную и дружную. Со мной тогда много носились: все объясняли, показывали, разговаривали — опять-таки, как по мне, уникальный случай. Думаю, редко где с джунами такое происходит.

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

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

Без портфолио к успеху

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

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

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

И основной поинт моей кулстори будет в следующем: как и почему я попал в геймдев с пустым портфелем? Что мне помогло преодолеть порог входа, когда повсеместно требуют несколько лет опыта работы, которых у тебя нет, и где же их взять? Тот самый замкнутый круг, знакомый многим непонаслышке. 

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

Это не сработало, но постепенно я нашел работодателя, открывшего у себя интернатуру. Что это значит? Тебя берут с улицы, говорят: «Ты только приди, и мы тебя всему научим. А когда ты у нас уже поработаешь некоторое время, мы тебе дадим денег, чтобы ты у нас остался». Если вам интернатуру еще и оплатят, это вообще высший пилотаж: мало кто у нас в стране так делает на локальном рынке, так что скажите такому работодателю «спасибо».

И, казалось бы, при чем здесь футболисты? А это олицетворение моей интернатуры: представим, что я — в желтой майке, а старший специалист, который меня учил — в синей. Он прибегает, отнимает у тебя мяч, с прыжка прыгает на грабли, бьет этими граблями себе по лбу, тебе по лбу, и после этого ты понимаешь, как можно было сделать лучше, а как — еще хуже, и учишься мало того, что на своих, но и на чужих ошибках. Кто-то любит говорить что испытательный срок не только для соискателя, но и для работодателя. Так вот, интернатура — это то же самое, только в квадрате: там тебя учат тому, что от тебя же впоследствии будут требовать. Это очень круто, я настоятельно рекомендую искать именно такие места.

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

А ниже в левой колонке показаны мобильные проекты, к которым я приложил руку: Vector, Vector 2, серия Shadow Fight. У нас команды тогда были достаточно маленькие, все занимались всем, до чего только дотянутся. Я там себя попробовал в разных ролях: я не сразу определился с тем, с чем именно я хочу иметь дело, так что «шило» у меня тогда совершало кульбиты невероятной сложности. В результате чего я попробовал себя и в роли левел-дизайнера, и геймдизайнера, и QA, PR, SMM, менеджера проекта… после чего все-таки остановился на левел-дизайне.

Когда у нас прошли платные релизы игр (кстати, мы релизились и в Steam, и на eShop, а версию для Nintendo Switch особенно рекомендую), я понял, что мне хочется сойти с поезда мобильного сегмента и войти в то, что сейчас принято называть сегментом премиальным (Steam, EGS, Xbox, PlayStation и тому подобное). Я списался с ребятами с проекта Atomic Heart. Они меня взяли одновременно с несколькими другими LD, но при этом по окончанию испытательного срока меня к тому же еще и сделали лидом. 

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

Что бы мне хотелось пожелать соискателям и новым сотрудникам?

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

Мысль в чем? Пробуйте решать проблемы словами через рот. Говорите со своими коллегами, пытайтесь понять, чего они от вас ждут. Все жанры уникальны, все студии уникальны, все проекты уникальны. Мало того: у каждого проекта внутри может быть несколько команд, и у каждой команды свои требования. А учитывая, что они-то, в отличие от вас, работают здесь не первый день, у них какие-то ожидания точно есть, и лучше их узнать.

Теперь посмотрим, что у нас справа. Почему Дрейк отмахивается от верблюда? 

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

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

А еще помните, что разработка игр — это не только ежедневный креатив, возможность как-то показать оригинальность своего мышления. Это разработка прикладного программного обеспечения с кучей технических задач — к подобному тоже надо быть готовым. Есть этапы, на которых геймдизайнерам дают максимальную свободу, а есть этапы, когда, так сказать, необходимо отступить в кулуары и помочь инженерам.

Наконец, что здесь делает скриншот из No Man’s Sky? Это одна реальная история из моей жизни. 

No Man’s Sky только вышел на рынок — и словил он рекордно низкую оценку. Здесь она даже приукрашена: изначально она была 11%, а не 12. Наиграл я тогда сразу на релизе 40 часов. Хожу после этого по кухне в офисе, чешу репу и думаю: «Почему я сперва испытывал такие эмоции, а потом — другие? Почему сперва было хорошо, а потом плохо? Может, у них проблемы с генережкой и они столкнулись с классической проблемой, когда на 80% прогресса — 20% контента?» Пытаюсь все это взвесить и понять, почему все именно так. Сидит рядом старший специалист и, услышав, что я бормочу под нос, отвечает: «Да д***мо какое-то, отыграл 30 минут, больше не осилил». 

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

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

Хотите куда-то попасть — сделайте что-нибудь для этого. Задать вопрос — хорошее начало. Особенно если он адресован нужному человеку.

Ребята из FPGA комунити каждый день делают небольшую подборку новостей из мира FPGA и решили поделиться ею с читателями хаба FPGA. Внимание: возможны повторы!

Свежие отечественные статьи

1. Что внутри ПЛИС или то, о чем не говорят в обучающих видео

2. Основы статического временного анализа. Часть 2.2: System Synchronous Output Delay Constraint.

3. Подключаем Slave-устройства с шиной Wishbone к системе на базе LiteX

4. PCIExpress 1.0 2.5GT/s analyzer на базе ПЛИС своими руками

5. HALF: целостное автоматическое машинное обучение для ПЛИС

6. FPGA: конечные автоматы с переключаемым контекстом

Остальное англоязычное

1. Implementation of Low-Density Parity Check on Field Programmable Gate Array DE1-SoC | IEEE Conference Publication | IEEE Xplore

2. Industry’s First COTS Mezzanine with 64 GSps ADC/DAC Sample Rates Is Introduced by Annapolis Micro Systems — Embedded Computing Design

3. Webinar Technitive | Open the Hardware: FPGA revolution Entradas, Jue, 3 feb. 2022 a las 16:00 | Eventbrite

4. Hardware-as-Code Part I: An Introduction — Hackster.io

5. PYNQ Now Available for the Kria KV260 Vision AI Starter Kit — Announcements — PYNQ

6. Introduction to FPGA Part 11 — RISC-V Softcore Processor | Digi-Key Electronics — YouTube

7. FPGA Calculator (Basys3) — Hackster.io

8. Measuring Circuit Delay for FPGA Timing using the ADP3450 — Hackster.io

9. AXI4-Lite Interface Wrapper for Custom RTL in Vivado 2021.2 — Hackster.io

10. Hello 2022 with Vintage Bubble Displays on the Arty Z7 — Hackster.io

11. Ruag teams for AI in space

12. Blueshift Memory adds UK industry veterans to advisory board

13. FPGA Vs Microcontrollers — Another Approach to Embedded Design

14. Common Mistakes in VHDL

15. Everything You Need to Know about SystemVerilog Arrays

16. Formal verification for SystemC/C++ designs — Tech Design Forum Techniques

17. Основы статического временного анализа. Часть 2.2: System Synchronous Output Delay Constraint. — Общее — Разное — Каталог статей — FPGA-Systems

18. FPGA Video AI deployment – From platform creation to AI deployment — Part 1

19. TE0865-02-FBE23MA • Sundance.com

20. Deploying Link™ Capture for Financial Applications

21. Project Ember | Hackaday.io

22. Programmable Photonics — Wim Bogaerts — Stanford — YouTube

23. FPGA Debug | Capture Gigabytes. At Speed.

24. Prototype and Adjust a Deep Learning Network on FPGA Video — MATLAB & Simulink

25. What is FPGA Zynq UltraScale+ with MPSoC? | Acromag

26. How Microchip FPGAs Can Improve Productivity in Motor Control Applications Using C++ with HLS | Microchip Technology

27. Industry’s First COTS Mezzanine with 64 GSps ADC/DAC Sample Rates Is Introduced by Annapolis Micro Systems — Annapolis Micro Systems, Inc.

28. Intel’s FPGA Day Unveils 3 Collabs to Create More FPGA-based IPU Designs — News

29. VHDL Generics – electgon

30. Basys3 Oscilloscope — Hackster.io

31. lvgl/lv_port_mps3_an547_cm55: A LVGL porting for Cortex-M55 running on an Arm official FPGA prototyping development board called MPS3 (AN547), see Figure 1. It is also possible to run the project template on an emulator called Corstone-300-FVP, which is free. Topics Resources

32. JLPEA | Free Full-Text | CORDIC Hardware Acceleration Using DMA-Based ISA Extension

33. Microcontroller in FPGA? This is how to do it … | Step by Step Tutorial | Adam Taylor — YouTube

34. ken-system: FPGA Implementation of Scalable Fully Coupled Annealing Processing Sysytem by Using Multi-chip Operation

35. Google Unveils the Coral Dev Board Micro, Its First Microcontroller-Based TinyML Edge AI Board — Hackster.io

36. QuickLogic Announces Australis™ eFPGA IP Generator :: QuickLogic Corporation (QUIK)

37. The VLSI Handbook: Design Principles, Industry and Career Perspectives eBook : Kumar, Udit , Gupta, Aditya, Soman, Sumit: Amazon.in: Kindle Store

38. MakarenaLabs/PYNQ-Microblaze-Tutorial: Simple tutorial for PYNQ that use microblaze for controlling GPIO

39. IPsec Engine | Silex Insight

40. How to Overcome the Pain Points of AI/ML Hardware Webinar

41. HDL Verifier — MATLAB & Simulink

42. Increase your productivity with Continuous Integration flows

43. How a robust FPGA supply chain assures defense industry preparedness — Military Embedded Systems

44. Semiconductor IP Verification | Exostiv Labs

45. New RF FPGA solutions transform EW platforms — Military Embedded Systems

46. 20220125 FPGA standup — YouTube

47. FPGA Frontrunners Meet & Greet Tickets, Wed 23 Mar 2022 at 09:30 | Eventbrite

48. 5G Open RAN

49. 3U VPX FPGA modules first to market with high-bandwidth memory

50. Array of Engineers Designs Custom SLVS-EC IP Core

51. Build your own video pipeline with PYNQ composable overlays | LinkedIn

52. RTLvision PRO Datasheet: Understand, Debug, and Integrate RTL Code, Easily — EDA Direct

53. What is an FPGA

54. racerxdl/riskow: Learning how to make a RISC-V

55. CPU, GPU, FPGA or TPU: Which one to choose for my Machine Learning training? – InAccel

56. EXOSTIV Blade — Scalable Visibility from Anywhere

57. The Future of Embedded FPGAs — eFPGA: The Proof is in the Tape Out — Circuit Cellar

58. Keysight Challenge NPB — YouTube

59. FOSDEM 2022 — Friends of OpenJDK devroom

60. MicroZed Chronicles: Scripting Vivado

61. How do you convert a design in FPGA to an ASIC? | Sondrel

62. Hog: HDL on git

63. hog / hog · GitLab

64. RehanEjaz/Pwm-FPGA-motor-speed-ctrl: Speed controller for DC motor to implement on FPGA

65. Five Reasons Why a High Performance Reconfigurable SmartNIC Demands a 2D NoC Webinar | Achronix Semiconductor Corporation

66. PUF over FPGA — 01 Course intro — YouTube

67. Q1_2022 Lattice Anti-Fragile Security & Post Quantum Crypto

68. Open MPW & chipIgnite — Getting Started

69. Multi-hetero Acceleration by GPU and FPGA for Astrophysics Simulation on oneAPI Environment | hgpu.org

70. Secure platform for cloud-based AI services | Xiphera

71. Hardware-as-Code Part I: An Introduction — Hackster.io

72. Are We Poised to Turn the Optical Computing Corner? – EEJournal

73. How does a flip flop work and why does it have setup & hold time? — YouTube

74. Netnod goes live with Arista FPGA implementation of Network Time Security (NTS) | Netnod

75. FPGA — DroneShield

76. China Approves Chipmaker AMD’s $35 Billion Acquisition of Xilinx — Bloomberg

77. Adaptive PMICs pair with PolarFire FPGAs — EDN

78. GOWIN Semiconductor USB 2.0 PHY Interface and Device Controller IPs Achieve USB-IF Certification

79. The Future of Embedded FPGAs — eFPGA: The Proof is in the Tape Out — Circuit Cellar

80. FPGA beginner course PUF over FPGA — 02 What is a PUF and discussion of the project structure — YouTube

81. Mastering the Migration Journey from Spartan-6 FPGAs to 7 Series and Beyond

82. Infineon Accelerates Development of IBIS-AMI Models for SerDes Designs — MATLAB & Simulink

83. How does a flip flop work and why does it have setup & hold time? — YouTube

84. China Approves Chipmaker AMD’s $35 Billion Acquisition of Xilinx — Bloomberg

85. Accelerate AI applications using VITIS AI on Xilinx ZynqMP UltraScale+ FPGA — Softnautics

86. Ethernet Communication using TCP protocol in Zynq processor in VIVADO 2018.2. — YouTube

87. Ruag teams for AI in space

88. In the Qwiic of Time — News — SparkFun Electronics

89. Deploying Deep Learning on Embedded CPUs, GPUs, and FPGAs Video — MATLAB

90. FPGA programming — what is it, how it works and where it can be used — CodiLime

91. Your access to this site has been limited by the site owner

92. Taming the Accelerator Cambrian Explosion with Omnia | LinkedIn

93. IBM doubles QRadar Network Insights performance

94. Multi-hetero Acceleration by GPU and FPGA for Astrophysics Simulation on oneAPI Environment | hgpu.org

95. 029 — Floating-Point FPGA Audio Limiter (1) | RTL Audio Lab

96. Semiconductor Engineering — Semiconductor events

97. Lattice SupplyGuard

98. Deep physical neural networks trained with backpropagation | Nature

99. The Future of Embedded FPGAs — eFPGA: The Proof is in the Tape Out — Circuit Cellar

100. 3U VPX FPGA modules first to market with high-bandwidth memory

101. Products of the Week: January 19, 2022 | Electronic Design

102. Analysis of the sales market for FPGA modules up to 2029 — winnquick.com

103. FPGA-based reliable TMR controller design for S2A architectures | IEEE Conference Publication | IEEE Xplore

104. Video: APA7-500 Series: User Configurable FPGA I/O Modules | Acromag

105. mjs19999/AES_in_verilog: An algorithmic state machine verilog code for AES Encryption/Decryption Algorithm

106. DO-254 Training: Learn This Important Standard for Aviation Hardware Safety | LinkedIn

107. Will the rise of AI and the Internet of Things subvert the design of Embedded Systems? | LinkedIn

108. Lattice Certus-NX Versa Evaluation Board Roadtest Review — element14 Community

109. DINI Group Announces HardwareSharkTM: Solves Packet Loss Issues in Wireshark With an FPGA-Based Memory Buffer. — Technology

110. HFT with FPGA — webinar

111. Porting incompressible flow matrix assembly to FPGAs for accelerating HPC engineering simulations | IEEE Conference Publication | IEEE Xplore

112. Implementation of NLOS based FPGA for distance estimation of elderly using indoor wireless sensor networks — ScienceDirect

113. Accelerate AI applications using VITIS AI on Xilinx ZynqMP UltraScale+ FPGA — Softnautics

Привет, Хаброжители! Вы фуллстек-разработчик, которому нужно развивать навыки фронтенд-разработки? Или фронтенд-разработчик, ищущий качественный обзор современных возможностей HTML и CSS? А может, вы создаете свой веб-сайт и хотите сделать его отзывчивым? Тогда, эта книга вам просто необходима! Со времени выхода предыдущего издания многое изменилось, теперь отзывчивый дизайн — это не новая технология, а стандарт разработки на HTML5 и CSS3. Неформальный и открытый стиль автора позволяет быстро освоить все возможности современного веб-дизайна. Вы получите практические знания о SVG, разметке HTML, создании потрясающей эстетики и эффектов с помощью CSS, переходах, преобразованиях и анимациях и многом другом. Если же вы опытный веб-игрок, то смело переходите к новым темам — гридам (CSS Grid layout) или вариативным шрифтам. К концу книги вы не только получите полное представление об отзывчивом веб-дизайне и возможностях последних версий HTML5 и CSS, но и узнаете, как максимально эффективно использовать эти знания на практике. Все, что нужно для начала работы, — это представление о том, что такое HTML и CSS.

Масштабирование (scale)

Для масштабирования используется следующий синтаксис:

.scale:hover {    transform: scale(1.4); }

Проход указателя мыши над ссылкой, имеющей класс scale, вызовет такой эффект:

Мы указываем браузеру при наведении на элемент указателя мыши увеличить этот элемент в 1,4 раза.

Использование значений меньше единицы приведет к сжатию элементов. Следующий код приведет к сжатию элемента до половины его размера:

transform: scale(0.5);

Перемещение (translate)

Для перемещения используется следующий синтаксис:

.translate:hover {     transform: translate(-20px, -20px); }

В нашем примере это правило приведет к следующему эффекту:

Свойство translate дает команду браузеру перемеcтить элемент на расстояние, определяемое длиной (например, vw, px, % и т. д.). Первое значение относится к перемещению по оси x, второе — по оси y. Положительные значения, заданные в скобках, приводят к перемещению элемента вправо или вниз, а отрицательные —соответственно, влево или вверх.

Если передается только одно значение, то оно применяется к оси x.

Если нужно указать для перемещения элемента значение только для одной оси, можно использовать объявления translateX(-20px), что в данном случае приведет к перемещению элемента влево на 20 px, или translateY(-20px), что в данном случае приведет к перемещению элемента вверх на 20 px.

Использование translate для центрирования элементов с абсолютным позиционированием
translate предоставляет удобный способ центрирования элементов с абсолютным позиционированием внутри контейнера с относительным позиционированием. Пример кода находится в каталоге example_09-03.

Рассмотрим разметку:

<div class="outer">     <div class="inner"></div> </div>

И этот код CSS:

.outer {   position: relative;   height: 400px;   background-color: #f90; }  .inner {   position: absolute;   height: 200px;   width: 200px;   margin-top: -100px;   margin-left: -100px;   top: 50%;   left: 50%; }

Возможно, вам уже приходилось делать нечто подобное. Когда известны размеры элемента с абсолютным позиционированием (в данном случае 200 px × 200 px), для «подталкивания» элемента обратно в центр можно воспользоваться отступами с отрицательными значениями. А как включить содержимое и насколько высоким оно окажется?

Добавим к внутреннему блоку произвольное содержимое.

Очевидно, возникла проблема. Разберемся с этим беспорядком с помощью transform:

.inner {    position: absolute;    width: 200px;    background-color: #999;    top: 50%;    left: 50%;    transform: translate(-50%, -50%); }

И вот результат:

Здесь top и left позиционируют блок внутри контейнера таким образом, что вначале левый верхний угол внутреннего блока находится в точке 50 % длины и 50 % высоты контейнера. Объявление transform работает в отношении внутреннего блока и позиционирует его в обратную сторону по этим осям на половину (-50%) его собственной ширины и высоты. Превосходно!

Поворот (rotate)

Преобразование rotate позволяет поворачивать элемент. Для него используется следующий синтаксис:

.rotate:hover {    transform: rotate(30deg); }

А в окне браузера произойдет следующее:

Значение в скобках всегда представляет угол поворота. Угол может выражаться в градусах, градианах, радианах и оборотах. Я предпочитаю градусы (например, 90deg). Положительные значения задают поворот по часовой стрелке, а отрицательные — против часовой стрелки.

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

transform: rotate(3600deg);

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

Наклон (skew)

Если вам приходилось работать в программе Photoshop, то наклон элемента по какой-либо из его осей или двум осям сразу вы уже представляете. Вот код примера:

.skew:hover {    transform: skew(40deg, 12deg); }

Установка этого правила для ссылки с псевдоклассом hover приведет при наведении указателя мыши на элемент к следующему эффекту:

Первое значение задает наклон по оси x (в нашем примере это 40deg), а второе значение (12deg) предназначено для задания наклона по оси y. Если опустить второе значение, то единственное имеющееся значение будет просто применено к оси x (горизонтальной оси), например:

transform: skew(10deg);

Как и в случае с перемещением, вы можете применять наклон только к одной оси с помощью функций skewX() и skewY().

Матрица (matrix)

Кто-нибудь вспомнил одноименный и весьма переоцененный фильм? Нет? Что-что? Вы хотите узнать о CSS-матрице, а не о фильме? Что ж…

Синтаксис преобразования matrix может показаться непостижимым. Рассмотрим пример кода:

.matrix:hover {    transform: matrix(1.178, -0.256, 1.122, 1.333, -41.533, -1.989); }<u></u>

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

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

Теперь мне нравятся сложные задачи (кроме просмотра серии фильмов «Сумерки»), но я уверен, что этот синтаксис требует исследований. Спецификация не совсем проясняет ситуацию: www.w3.org/TR/css-transforms-1/#mathematical-description.

Можно сосчитать на пальцах одной руки, сколько раз мне потребовалось написать или понять преобразование CSS, описанное как matrix, поэтому о нем, пожалуй, не стоит беспокоиться.

Если понадобится создать матрицу, обратитесь по адресу:
www.useragentman.com/matrix.

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

Свойство transform-origin

Обратите внимание, что при использовании CSS исходная точка преобразования, которую браузер использует в качестве центра, находится посередине — на 50 % протяженности элемента по оси x и на 50 % его протяженности по оси y. Это отличается от SVG-технологии, в которой такая точка по умолчанию находится в левом верхнем углу с координатами (0; 0).

С помощью свойства transform-origin можно изменить точку начала преобразования.

Рассмотрим наше матричное преобразование. По умолчанию transform-origin устанавливает точку начала преобразования в позицию ‘50% 50%’ (в центре элемента). Средства разработчика Firefox показывают, как это преобразование применяется.

Если перенастроить значение transform-origin таким образом:

.matrix:hover {    transform: matrix(1.678, -0.256, 1.522, 2.333, -51.533, -1.989);    transform-origin: 270px 20px; }

то можно увидеть следующий эффект:

Первое значение задает смещение по горизонтали, а второе — по вертикали. Можно использовать ключевые слова. Например, left задает 0 % по горизонтали, right — 100 % по горизонтали, top — 0 % по вертикали и bottom — 100 % по вертикали. Или воспользуйтесь длиной, задавая для нее любые единицы измерения, используемые в CSS.

Если для значений свойства transform-origin используются проценты, то горизонтальное и вертикальное смещения задаются относительно высоты и ширины контейнера, содержащего элементы.

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

Спецификация CSS 2D Transforms Module Level 1 находится по адресу: https:// www.w3.org/TR/css-transforms-1.

Более полно преимущества перемещения элементов с помощью преобразований рассмотрены в статье Пола Айриша (Paul Irish) (http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/).

А в качестве просто фантастического обзора того, как браузеры справляются с переходами и анимацией, и объяснения, почему преобразования могут быть столь эффектными, настоятельно рекомендую следующую публикацию: blogs.adobe.com/webplat-form/2014/03/18/css-animations-and-transitions-performance.

Мы рассмотрели основы преобразований в двух измерениях, по осям x и y. Тем временем CSS-код способен обрабатывать элементы в трехмерном пространстве. Посмотрим, как можно получить еще больше удовольствия с помощью 3D-преобразований.

Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — HTML5

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

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

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

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

lastname = Ivanov  firstname = Petr middlename = Sidorovich

XML-представление займет 106 байт, JSON: 77 байт.

Если сравнивать с длиной исходных строк (дополнительно предусмотрим +1 байт для окончания или длины строки), то объем исходного сообщения составит 23 байта, объем JSON-документа составляет 335% от исходного, а XML — 461%. Это очень значительные затраты и они становятся еще больше при передаче сложных объектов с большим количеством числовых полей. 

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

Да, и cуществует целое семейство двоичных протоколов сериализации (MessagePack, Thrift), но сейчас для нас наибольший интерес будет представлять протокол Protocol Buffers (protobuf), предложенный в 2008 году корпорацией Google. Протокол позволяет передавать следующие типы данных:

• Целые числа (32 и 64-разрядные, со знаком и без знака) — int32, int64, sint32, sint64

• Строки — string

• Числа с плавающей точкой (одинарной и двойной точности) — float, double

• Логические типы — bool

• Перечисление — enum

• Любые другие зарегистрированные типы сообщений

• Массивы из значений — repeated

• Словари из значений — map

• Произвольный массив байтов — bytes

Дополнительно могут подключаться расширения, для кодирования специальных типов данных (например, google/protobuf/timestamp.proto для отпечатка времени, тип google.protobuf.Timestamp)

Описание структуры сообщений и доступных действий выполняется на специальном языке (в настоящее время proto3) и записываются в proto-файле.

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

syntax = "proto3";  package ru.grpctest;  message User {   string lastname = 1;   string firstname = 2;   string middlename = 3;   int32 age = 4;   enum Gender {     MALE = 0;     FEMALE = 1;   }   Gender gender = 5; }  message RegistrationResult {   bool succeeded = 1;   string error = 2; }  service RegistrationService {   rpc Register(User) returns (RegistrationResult); }

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

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

protoc -I=исходный_каталог --java_out=каталог_проекта --kotlin_out=каталог_проекта registration.proto

Важно отметить, что несмотря на тот факт, что Kotlin позволяет использовать богатые возможности по созданию предметно-специфических языков (включая функции расширения с получателем и инфиксные операторы), эти возможности стали использоваться для создания объектов-посредников в protobuf относительно недавно и только в ноябре 2021 года Google официально объявила о поддержке DSL при генерации классов с использованием protoc (подробности здесь: Announcing Kotlin support for protocol buffers)

Но кодирование сообщения — это только часть проблемы, необходимо еще ускорить транспортный канал и постараться избежать дополнительных расходов на установку соединения и обмен служебной информацией. Поскольку исторически взаимодействие микросервисов организуется посредством веб-протоколов, то это хорошая причина искать возможность среди обновленных протоколов Интернет. Наиболее подходящим кандидатом для использования в качестве транспорта является одна из двоичных реализаций протокола HTTP, среди которых актуальными на 2022 год являются протоколы QUIC (принят в качестве официального стандарта в RFC 9000) и HTTP/2 (RFC 7540). Общими чертами всех двоичных протоколов можно назвать сжатие заголовков, мультиплексирование запросов и поддержку полнодуплексного режима для длительного соединения, что делает их идеальными кандидатами для обмена сообщениями в микросервисных архитектурах.

Объединяя лучшее из двух миров, в 2016 году корпорацией Google был предложен протокол для передачи сообщений и вызова удаленных методов, получивший название gRPC (который стал развитием внутреннего проекта Stubby, созданного для ускорения взаимодействия микросервисов). Вопреки известному заблуждению, буква g не обозначает Google, она меняет свое значение в каждой новой версии протокола (в актуальной версии 1.45 она обозначает gravity). gRPC работает поверх протокола HTTP/2.0 и поддерживается практически всеми веб-серверами и API Gateway, объединяющих системы на основе микросервисов.

Исторически первой библиотекой для создания gRPC-совместимых сервисов на JVM была gRPC-Java, основанная на использовании StreamObserver для поддержки диалога при обмене сообщениями между микросервисами. Очевидным следствием такой реализации становилось увеличение количества вложенных блоков кода, что усложняло чтение и отладку и фактически являлось проявлением callback hell. Кроме этого, для создания сообщений (единица обмена информацией в gRPC) использовались Builder-ы с bean, что увеличивало объем кода и приводило к появлению длинных цепочек подготовки данных.

Например, для отправки сообщения с тремя полями и анализа ответа, код (на Kotlin) мог выглядеть подобным образом:

val request = RegisterRequest.newBuilder().setFirstName("Ivan").setLastName("Ivanov").setAge(22).build() stub.goRegister(request, object: StreamObserver<RegistrationResponse> by DefaultStreamObserver() {   override fun onNext(data: RegistrationResponse) {     stub.doRegisterConfirmation(data.token, object: StreamObserver<RegistrationConfirmation by DefaultStreamObserver() {       override fun onNext(data: RegistrationResponse) {         stub.doRegisterComplete(data.token);       }     })   } }) 

Очевидным решением для Kotlin являлось использование корутин вместо асинхронных подписок на потоки. В этом месте эволюция разделилась на несколько параллельных ветвей:

1. часть библиотек начала создавать обертки вокруг gRPC-Java и добавлять полезные расширения, при сохранении общей концепции генерации сообщений (поскольку builder-классы создаются официальным инструментом Google для кодогенерации на основе proto-файла)

2. другие библиотеки стали реализовывать полностью независимую реализацию протокола gRPC, одновременно решая задачу разработки plugin’ов для систем сборки (чаще всего gradle) для кодогенерации по информации из proto-файла.

К первой группе относятся библиотеки Kert (многопротокольный веб-сервер, поддерживает HTTP / GraphQL / с версии 3.0.0 поддерживает также gRPC, вызов функций выполняется с использованием корутин, потоковый обмен данными использует преимущества Flow, предлагает свою реализацию для кодогенерации, аналогичную protoc), Kroto+ (предоставляет возможность вызова сервисов как корутин с возможностью отмены ожидания, реализует собственный Gradle Plugin для создания DSL на основе информации о структуре сообщений, к сожалению не обновляется и не поддерживается уже почти 2 года). И конечно необходимо отметить библиотеку grpc-kotlin, которая в 2020 году опубликована Google под открытой лицензией и является развитием исходной библиотеки grpc-java с использованием возможностей языка программирования Kotlin.

Ко второй группе можно отнести библиотеку Wire, которая полностью реализует протокол gRPC и предлагает модель потоков данных на основе MessageSource / MessageSink и собственную кодогенерацию. Возможности DSL в настоящее время не используются.

Выполним сравнение кода определения сообщения с использованием различных библиотек и вызовом сервиса регистрации:

Kert / gRPC-java:

val user = User.Builder().setLastname("Ivanov").setFirstname("Petr").setMiddlename("Sidorovich").setAge(23).build(); stub.Register(user)

Wire:

val user = User(lastname = "Ivanov", firstname = "Petr", middlename = "Sidorovich", age = 23) GrpcClientProvider.grpcClient.create(RegisterClient::class).Register().execute().let {    (sendChannel, receiveChannel) -> sendChannel.offer(RegisterCommand(user=user))  } 

Kroto+

val user = User {   lastname = "Ivanov"   firstname = "Petr"   middlename = "Sidorovich"   age = 23 } stub.Register(user)

На стороне сервера в Kroto+ функция Register помечается как suspend и формирует ответ в виде сообщения (объекта соответствующего типа или DSL-инициализатора, создающего этот объект в return)

Особое внимание хотелось бы уделить библиотеке grpc-kotlin, которая официально поддерживается Google и поддерживает как использование корутин, так и манипуляции с сообщениями и вызовами с использованием DSL.

Сделаем два микросервиса и настроим обмен сообщениями между ними с использованием grpc-kotlin:

1) Добавим в build.gradle в repositories модуля источник google()

2) В plugins подключим 

id("com.google.protobuf") version "0.8.18"

 3) В dependencies подключим библиотеку

implementation("com.google.protobuf:protobuf-kotlin:3.19.4") api("io.grpc:grpc-protobuf:1.44.0") api("com.google.protobuf:protobuf-java-util:3.19.4") api("com.google.protobuf:protobuf-kotlin:3.19.4") api("io.grpc:grpc-kotlin-stub:1.2.1") api("io.grpc:grpc-stub:1.44.0")

4) Добавим блок конфигурации protobuf

protobuf {     protoc {         artifact = "com.google.protobuf:protoc:3.19.4"     }     plugins {         id("grpc") {             artifact = "io.grpc:protoc-gen-grpc-java:1.44.0"         }         id("grpckt") {             artifact = "io.grpc:protoc-gen-grpc-kotlin:1.2.1:jdk7@jar"         }     }     generateProtoTasks {         all().forEach {             it.plugins {                 id("grpc")                 id("grpckt")             }             it.builtins {                 id("kotlin")             }         }     } }

5) Для поддержки запуска сервера необходимо установить библиотеку встроенного веб-сервера с поддержкой grpc (например, grpc-netty) в dependencies. Аналогично может использоваться расширение ktor с поддержкой gRPC.

runtimeOnly("io.grpc:grpc-netty:1.44.0")

6) Добавим импорт в build.gradle

import com.google.protobuf.gradle.*

Далее создадим каталог protobuf в /src/main, разместим файл register.proto (был приведен выше) и добавим конфигурацию build.gradle:

sourceSets {     main {         proto {             srcDir("src/main/protobuf")         }     } }

Проверим сборку проекта, для этого выполним ./gradlew assemble

После генерации классов на основе proto-файлов для каждого сервиса создается объект с названием <ServiceName>GrpcKt, предоставляющего для использования в Kotlin несколько заглушек:

• <ServiceName>CoroutineStub — заглушка для вызова сервиса как suspend-функции;

• <ServiceName>CoroutineImplBase — базовый класс для реализации на сервере (как suspend-функции).

Также создается класс <ServiceName>Grpc с заглушками для использования в Java-коде (и для совместимости с ранее созданными библиотеками на основе gRPC-Java):

• <ServiceName>ImplBase — базовый класс для серверной реализации метода, использует StreamObserver для отправки и получения ответа в длительном диалоге;

• <ServiceName>Stub — заглушка для вызова сервиса с подпиской на поток;

• <ServiceName>BlockingStub — заглушка для вызова сервиса с блокировкой выполнения до получения ответа;

• <ServiceName>FutureStub — заглушка для вызова сервиса с получением объекта ListenableFuture для отслеживания получения ответа.

Создадим клиентскую часть приложения:

import io.grpc.ManagedChannelBuilder  suspend fun main() {     val port = 50051      val channel = ManagedChannelBuilder.forAddress("localhost", port).usePlaintext().build()     val stub = RegistrationServiceGrpcKt.RegistrationServiceCoroutineStub(channel)     val data = user {         lastname = "Ivanov"         firstname = "Petr"         middlename = "Sidorovich"         age = 23         gender = Register.User.Gender.MALE     }     val result = stub.register(data)     print("Success is ${result.succeeded}") }

Обратите внимание, что вызов функции register является корутиной (ответ возвращается асинхронно), поэтому функция main так же помечена как suspend. При использовании кода внутри обработчиков в веб-серверах (например, в ktor) это подразумевается по умолчанию.

Создадим для проверки в этом же проекте серверную часть приложения:

import io.grpc.ServerBuilder  private class RegistrationService : RegistrationServiceGrpcKt.RegistrationServiceCoroutineImplBase() {     override suspend fun register(request: Register.User): Register.RegistrationResult {         print("Registering user ${request.lastname} ${request.firstname} ${request.middlename}, age: ${request.age}, gender: ${request.gender.name}")         return registrationResult { succeeded=true }     } }  fun main() {     val port = 50051     //prepare and run the gRPC web server     val server = ServerBuilder         .forPort(port)         .addService(RegistrationService())         .build()     server.start()     //shutdown on application terminate     Runtime.getRuntime().addShutdownHook(Thread {         server.shutdown()     })     //wait for connection until shutdown     server.awaitTermination() }

Последовательно запустим серверную и клиентскую часть приложения и убедимся, что gRPC канал работает в обоих направлениях.

Server.kt Registering user Ivanov Petr Sidorovich, age: 23, gender: MALE  Client.kt Success is true

Создание сообщений в grpc-kotlin осуществляется с использованием DSL-синтаксиса (название генератора совпадает с названием класса со строчной буквы), при этом поля, которые помечены как repeated будут доступны как коллекции List, а поля с типом map будут реализованы как DslMap, поддерживающего основные методы чтения и модификации данных, аналогично типу Map. Простые типы данных транслируются в соответствующие типы Kotlin, для поля с типом enum создается вспомогательный статический класс с перечислением именованных констант. 

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

Исходный текст проекта размещен на github: https://github.com/dzolotov/kotlin-grpc-sample

Также хочу пригласить всех на бесплатный демоурок курса Kotlin Backend Developer, который пройдет уже 9 февраля на платформе OTUS. Регистрация доступна по ссылке.

Это перевод интервью с Харальдом Лейтнером (Harald Leithner) и Нильсом Брачеком (Niels Braczek) — они вместе возглавляют релиз Joomla 5, который сейчас находится на стадии планирования.

— Харальд: Как и многие другие участники проекта Joomla, я начал работу с Joomla ещё с Mambo. Но долгое время только как пользователь. Пару лет назад я посетил Joomladay и присоединился к сообществу. После этого события я очень быстро включился в работу над ядром, присоединившись к JSST (Joomla! Security Strike Team), а затем стал руководителем релиза 3.9.3+ и координатором производственного отдела (Production Department).

— Нильс: Я вошел в мир Joomla с Mambo 4.6, непосредственным предшественником Joomla 1.0. На тот момент я уже более 25 лет занимался разработкой программного обеспечения в самых разных средах. Mambo был отличным инструментом для быстрого и простого создания веб-сайтов, которые можно было расширять по своему усмотрению. Однако некоторые вещи казались довольно незрелыми (некоторые, возможно, помнят монстра $mainframe).

Я только начал писать свою собственную CMS, которая должна была использовать расширения Mambo, когда разработчики взбунтовались и запустили Joomla. То, что я слышал о планах и идеях Joomla, совпадало с моими целями, поэтому я решил присоединиться к Joomla, а не заниматься своей разработкой.

Харальд и Нильс, не могли бы вы напомнить мне о вашем участии в Joomla, работали ли вы раньше над релизами или планированием структуры Joomla?

— Харальд: Помимо поддержки серии 3.9.3+ в течение 2 лет, я был вовлечен в разработку компонента процессов (Workflow) в его нынешнем виде и многие другие аспекты Joomla 4. Но моя основная работа заключается в поддержании стабильности CMS и фреймворка. Такие вещи, как предотвращение нарушений обратной совместимости, контроль производительности и безопасности, работа над инфраструктурой тестирования.

— Нильс: На мероприятии по запуску Joomla 4 в Афинах у меня была возможность представить свои идеи о Joomla, какой она должна быть. В основе было разделение ввода и вывода от обработки, так что «контент» не ограничивался бы вебом, а обслуживал бы все возможные каналы. Кроме того, существовала так называемая «ортогональная архитектура», которая должна была гарантировать, что определенные сервисы, такие как контроль доступа, теги, процессы и т.д. будут доступны всем компонентам без дополнительного кода.

Некоторые люди были в восторге от возможностей, которые это открывало, другие яростно сопротивлялись таким глубоким изменениям. В конце концов, было принято решение развивать Joomla 4 небольшими шагами и рассматривать новую концепцию как путеводный маяк проекта, «Joomla X».

Многое из того, что мы разработали для Joomla X, в конечном итоге нашло свой путь в Joomla 4. Однако, из-за продолжающегося сопротивления новой архитектуре, команда Joomla X стала командой архитектуры и стратегии программного обеспечения (Software Architecture and Strategy Team), сместив фокус с предоставления концептуального кода на консультирование разработчиков по архитектуре. Как и Joomla X, SA&S находится под моим руководством.

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

— Харальд: В версии 5.0 я бы хотел увидеть полную очистку всех функций и моделей поведения, уже помеченных как устаревшие. За время существования такого программного проекта, как Joomla, функции добавляются, а кодовая база становится все более сложной и не поддается сопровождению. В Joomla 4.0 мы получили более перспективное обновление архитектуры. Также был введен b/c слой (слой обратной совместимости) для расширений Joomla 3, который планируется убрать в 5.0. Кроме того, новая система событий должна полностью заменить старую, с четко определенными событиями, включая валидацию.

В качестве улучшения CMS я бы хотел видеть поддержку PHP 8.1 Fibers, а также поддержка Revolt или даже React PHP была бы одной из особенностей, которые я хотел бы увидеть в Joomla 5.0.

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

— Нильс: На данный момент я могу говорить только о своих личных идеях, потому что окончательное решение о масштабах Joomla 5 еще не принято.

Несомненно, необходимо избавиться от старого бремени — это и есть настоящая цель новой мажорной версии. Если бы была полная обратная совместимость, то не было бы необходимости в 5.0, тогда было бы достаточно 4.x. Таким образом, мы можем в полной мере воспользоваться потрясающими возможностями, которые предлагает PHP 8.1.

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

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

Должен быть пересмотрен процесс установки, чтобы Joomla и расширения можно было легко устанавливать и обновлять через командную строку. В идеале, мы должны использовать для этого Composer, инструмент, который может разрешать зависимости и предоставлять нужные пакеты. Это даст разработчикам расширений простой способ включать сторонние библиотеки, не вызывая конфликтов. Это также позволит хостинг-провайдерам устанавливать Joomla из своей панели управления. Создатели сайтов могут описать полную установку в одном JSON-файле и настроить ее с помощью одной команды CLI.

Развитие Joomla в направлении headless CMS должно быть более расширенным. Улучшение веб-интерфейса API и разделение каналов CMS и вывода открывает перед сайтостроителями совершенно новые возможности. Конечные точки API и команды CLI должны генерироваться автоматически, насколько это возможно. Одним из больших преимуществ этого является возможность создания кэша страниц, т.е. хранения предварительно отрендеренных страниц, которые могут обслуживаться непосредственно веб-сервером и загружать свое динамическое содержимое по требованию через вызов API.

Как уже упоминалось в начале, Joomla 5, естественно, не будет полностью обратно совместима с Joomla 4. По мере возможности мы будем предлагать изменения в архитектуре, уже в Joomla 4, как альтернативу предыдущей, чтобы сохранять прямую совместимость. Таким образом, необходимые корректировки для поддержки Joomla 5, должны быть возможны для разработчиков расширений на ранней стадии. Я также хотел бы использовать Rector, инструмент, который может перестраивать программный код в соответствии с правилами, для того, чтобы обеспечить поддержку разработчиков в том, чтобы сделать их расширения совместимыми с Joomla 5 как можно раньше.

Это самые важные вещи, которые я хотел бы видеть в Joomla 5. Есть также куча мелочей, которые можно улучшить, или мест, где не хватает совсем немного, чтобы сделать действительно отличный функционал. Однако перечислять их все здесь — значит выйти за рамки этой статьи.

Как вы планируете работать вместе, будете ли вы оба работать над одними и теми же областями или разделите задачи, и если да, то кто будет отвечать за какие задачи?

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

Одна из причин, по которой у нас есть два лидера релиза для этой версии, заключается в том, что мы не хотим тратить еще 5 лет на следующую мажорную версию. Я уже смог ускорить выпуск Joomla 4.0, и я уверен, что смогу успеть к сроку выпуска Joomla 5.0.

С другой стороны, мы не одни отвечаем за выпуск Joomla 5.0, за нами стоит команда CMS Release Team и CMS Maintenance Team, поэтому мы координируем работу со всеми другими сопровождающими и постоянно общаемся с CMS Release Team.

— Нильс: Это хороший вопрос! Мы его еще не обсуждали.

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

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

Мы также хотим более тесно сотрудничать с командой CMS Release Team, чем это было в прошлом.

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

— Харальд: Сообщество является для нас самым важным источником информации, поэтому мы будем очень признательны за любые отзывы, идеи и пожелания. У нас есть процесс RFC, о котором Нильс расскажет позже, и, конечно же, с нами можно связаться напрямую через Joomla! Volunteers Portal, Glip или любой другой канал. В зависимости от источника идеи она должна включать всю необходимую информацию, такую как преимущества, причины, проблемы, влияние и так далее. У вас очень короткий срок, поэтому мы будем признательны, если вы обратитесь к нам как можно скорее. 

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

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

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

Для этих целей мы создали процесс RFC. На сайте https://github.com/joomla/rfc есть инструкции по использованию этого процесса. Не волнуйтесь, это кажется сложнее, чем есть на самом деле! Чтобы начать процесс, необходимы только две вещи: краткое описание того, о чем идет речь, и обоснование (Why Bother) того, почему это так важно и должно быть обязательно реализовано. Если вы хотите использовать список рассылки для вашего предложения вместо GitHub, пожалуйста, пометьте ваши предложения в теме письма как [Joomla 5].

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

Существует тесная синергия между разработчиками ядра и расширений.

Есть ли какие-либо идеи и предложения, которые помогут разработчикам расширений?

— Харальд: Разработчики расширений являются важной частью экосистемы CMS. Поэтому мы хотим как можно скорее дать им рекомендации по изменениям в Joomla 5. Кроме того, мы хотим убедиться, что обновление расширения с 4 на 5 будет максимально простым, например, расширение j4 должно работать на j5 без особых изменений.

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

Сможем ли мы использовать Rector так, как мне хотелось бы, к сожалению, пока не ясно.

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

— Харальд: Да! Разработчики расширений часто знают CMS лучше, чем мы. Поэтому любая помощь будет очень ценна. Например, начать тестирование как можно скорее или вложить время в разработку было бы очень приятно.

— Нильс: Определенно! Чем раньше мы получим обратную связь от разработчиков, тем лучше мы сможем учесть их потребности. Конечно, мы были бы просто счастливы, если бы разработчики расширений могли предоставить рабочую силу для разработки. Всегда есть чем заняться, а рук слишком мало.

Joomla 4 пробыла на стадии создания довольно долго. Какие надежды вы возлагаете на Joomla 5 и какой временной масштаб вы считаете реалистичным и достижимым? Я вижу, что Joomla 4.1 до сих пор жестко контролировалась по времени, планировалось, что она выйдет через 6 месяцев после Joomla 4.0. Как вы думаете, возможен ли такой жесткий и надежный план выпуска для крупного релиза?

— Харальд: Как уже упоминалось, это одна из моих целей. Долгое время разработки Joomla 4 было большой проблемой для сообщества, и я рад, что мы наконец-то выпустили её в день рождения Joomla. В рамках Joomla 4 мы перешли на 6-месячный цикл релизов, что означает, что мы выпускаем минорную версию каждые 6 месяцев. Исходя из этого, мы планируем выпустить Joomla 5.0 17 августа 2023 года. Как только мы начнем разработку Joomla 5, мы составим дорожную карту релизов с указанием всех основных этапов.

— Нильс: В основном существует два типа планов релиза: основанные на функциях или ограниченные по времени. У нас есть политическое решение, которое навязывает релизы с временными рамками. Поэтому, если правила игры не изменятся до этого момента, Joomla 5 будет выпущена 17 августа 2023 года. Для нас, как руководителей релиза, это означает, что мы должны завершить все архитектурные изменения к первому альфа-релизу. После этого никакие изменения в архитектуре больше не могут быть сделаны. Параллельно будут разрабатываться функции, которые должны быть завершены к началу бета-фазы. С этого момента будут устраняться только ошибки. Все, что не будет завершено к этому времени, будет ждать следующего релиза. Пока мы не можем назвать сроки альфа- и бета-фаз, так как они еще не определены. Следите за дорожной картой, чтобы узнать подробности.

Помимо того, что мы можем рассказать вам, что мы хотели бы видеть в Joomla 5, чем мы можем еще помочь?

— Харальд: Мы принимаем любую помощь, которую можем получить. Поскольку Joomla! — это 100% CMS, управляемая сообществом, она нуждается в участии каждого члена сообщества. Так что если вы получаете удовольствие от кодинга, написания документации, поддержки нашей инфраструктуры, тестирования CMS, предоставления отзывов, основанных на «реальном мире», или просто хотите сказать спасибо, мы будем рады каждому.

— Нильс: Всегда не хватает трех вещей: Входных данных, обратной связи и рук. Если вы хотите помочь Joomla и умеете программировать, помогите нам с внедрением. Если вы хотите помочь Joomla и умеете писать, помогите нам с документацией. Если вы хотите помочь Joomla и умеете общаться, помогите нам донести информацию. Если вы хотите помочь Joomla, но вышеперечисленное вам не подходит, свяжитесь с командой по работе с волонтерами (Volunteers Engagement Team) — они найдут для вас место!

Спасибо, Харальд и Нильс.

Полезные ресурсы

Ресурсы сообщества

https://joomlaforum.ru/ — форум русской поддержки Joomla.

https://joomlaportal.ru/ — интернет-портал Joomla-сообщества.

Telegram

https://t.me/joomlaru — чат сообщества «Joomla! по-русски».

https://t.me/projoomla — Joomla для профессионалов и опытных пользователей, разработчики Joomla.

https://t.me/joomlafeed — новости о Joomla! и веб-разработке по-русски.

https://t.me/joomla_jobs — вакансии и предложения работы по Joomla: фуллтайм, частичная занятость и разовые подработки. Размещение вакансий здесь.

https://t.me/joomlatalks — англоязычный чат сообщества.