SIGGRAPH

Давно ничего не писал из-за завала по проектам) Нооо пора исправляться) Я обожаю смотреть всякие лекции и интересные доклады, и чтобы понимать что происходит в графике SIGGRAPH всегда обязателен к просмотру так же, как и Unite для Unity разработчиков) https://www.youtube.com/watch?v=vn-WzWm74Pc Конечно подобные штуки не для реалтайма, но по ним уже видно на что способны современные компьютеры в плане графики, симуляций всяких материалов и т.п. Плюс очень часто там можно "подсмотреть" интересные подходы и работы. Не всегда такие сложные, допустим если мы говорим про одежду, то интересно (хотя визуально попроще) она сделана в NFL 21 https://www.youtube.com/watch?v=_x3PBfk0-ww

Очень трудно стать экспертом работая в крупной компании

Сегодня я наткнулся на весьма любопытный ролик с которым я в целом согласен. Там есть 4 критерия того "в какой среде надо находится, чтобы стать экспертом". Если коротко по 4 пунктам

1) Множество повторений — это в целом путь изучения чего угодно. Я всегда был за обучение через практику, так как написав 40 раз одну и ту же задачу, ты делаешь её на автомате. В том числе поэтому в своих проектах я в среднем против использования готовых ассетов для мелкого функционала. Понятное дело "писать свой AVPro для практики" — глупая задача. Но всякие мелочи типа скриптов управления или камеры, полезно именно писать даже чисто для разминки. Пока это не станет автоматическим действием, как у меня. Условно мне дольше зайти на ассет стор и скачать ассет/поискать в гугл, чем написать свой Pinch, Zoom для управления мобилок или ограничитель камеры

2) Достоверная среда — в этом плане повезло с программированием. У нас среда почти всегда достоверная, как и в шахматах или в любой технической штуке. В том же покере (я когда-то был про игроком) всё немного сложнее. Конечно же я сыграл более 1 миллиона рук за свою карьеру. Но эту среду трудно считать достоверной без системы статистики. Ну то есть запомнить все руки невозможно + покер классно обманывает нас по психологии. Человеческий мозг так устроен, что он лучше запоминает яркие события. Поэтому "выигрыш на рандоме" запоминается лучше правильной игры. Просто про игроки каждую неделю разбирают свои сыгранные руки (так как я играл онлайн у меня была история рук, где можно было разобрать свои ошибки и причины). В офлайне интересные руки можно запоминать осознанно. Так как играя в про стиле ты будешь играть за 4-5 часов в среднем около 20-30 рук, что не так много информации. Но в разработке всегда результат достоверен)

3) Своевременная обратная связь — вот тут уже есть нюансы. С обычной работой программы исхода два "работает" и "не работает". Ты быстро обучаешься видеть классические баги, закономерности и т.п. И тут всё действительно просто. Многие баги я нахожу очень быстро, так как "я уже это всё видел". Причём даже в чужом коде, так как на самом деле даже в самой плохой архитектуре есть типовые паттерны и закономерности. Но вот архитектура даёт обратную связь совсем не сразу, если тут нет лида который даёт фидбек) Говорит о нюансах и т.п. Поэтому в ней на самом деле меньше всего экспертов. Особенно в продуктовых компаниях среди людей, которые работают по куче лет над одним проектом. Бывают исключения, люди которые прочитали все книги. Разбирают на досуге чужие репозитории (обожаю этим заниматься) и их архитектуру, кто сильно вкладывается в своё самообучение, но это единицы. Большинство читают мантру SOLID, DI и IoC, и выжимки из чистой архитектуры. А книжные знания в архитектуре имеют некоторую проблему. В контексте каждого проекта применим свой подход. Есть критика солида, DI и т.п. Есть другие подходы, есть куча архитектурных схем. И по сути каждая более или менее применима под контекст проекта. Единственный общий принцип для всего KISS :) Который очень часто в таком случае нарушают) И для его тренировки я очень рекомендую разбирать чужие репы. На своём коде трудно понять, что "он сложный". А вот на чужом легко) И опять таки начинаешь видеть закономерности сложного кода

4) Преднамеренная практика — и вот этот пункт самый сложный для выполнения в крупной компании. Побывать в крупной компании полезно, так как это свой контекст и надо понимать, как она работает и "её мышление". Но с точки зрения того же разработчика, ты через время, особенно когда сервис переходит в стадию оперирования начинаешь "делать одно и тоже без развития" и деградировать. Опять таки, есть люди которые самостоятельно практикуются дома, имеют пет проекты или истории типа моих статей. Чисто чтобы не "костенеть". Но я чаще всего уходил из компаний, так как я переставал получать новый опыт в принципе. Я просто делаю одно и тоже и не развиваюсь, значит мне пора дальше) Поэтому видимо в конце концов я пришёл в аутсорс, где по сути за 4 года я сделал больше 60 проектов. И каждый не особо похожий на другой) Когда проект новый (в крупной компании), то там чаще всего бывает интересно. Но на такой проект бывает трудно попасть)

И с чем я точно согласен в видео, что экспертность — это по сути про распознавание ситуаций и закономерностей, но достоверное. То есть по сути очень глубокая насмотренность. И это начинает казаться интуицией) Но по факту ты просто уже всё это видел, и понимаешь либо "куда смотреть", либо "к чему это приведёт". Рекомендую всем кто хочет стать эксперта завести себе простую привычку, чтобы не убивать много времени. Разбирать какой-нить репозиторий 1 раз в месяц. Не особо большой, для этого отлично подходят репозитории Keijiro Takahashi но можно и любые другие. И разбирая стараться замечать "что вам непонятно и почему". Это сильно увеличит качество вашего кода, так как проще будет видеть такие проблемы в своих решениях)

Насмотренность и работа

Как небольшой комментарий к прошлому посту (а то и так получился огромный лонгрид разбитый аж на два сообщения) Тоже самое про смену работы/проекта и почему это полезно. Важно иметь некоторую насмотренность различных решений. И в крупных компаниях часто решения бывают хорошие, поэтому можно посмотреть "как делается хорошо". Но побывав в нескольких крупных компаниях ты ещё понимаешь, что "хорошо бывает по-разному". Поэтому раз в N-ый период времени (у меня это было около года) полезно менять компанию или проект. Помимо того, о чём я писал в статье. Так же такой подход позволяет смотреть на "долгосрочные проблемы архитектурных решений". Если вдруг в компании какой-то проект начинает сыпаться и тонуть в техдолге

Чтож пора про что-то и со сцены рассказать осенью на https://mixrconf.ru :)

Версии и контент

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

У нас условия правда ещё сложнее. Контент делает несколько других команд и поставляет бандлами — и это ад. Когда система усложняются начинаешь постепенно сталкиваться с такой вещью как "баги Unity" и многие из них юнити часто правят. Но когда контент делался год, третьими лицами, а баг в новом контенте является критическом — ты в ловушке. Обновить юнити нельзя (упадёт весь старый контент), поправить баг нельзя (бывают баги без workaround). И поэтому всегда нужно помнить, что если проекту будет несколько лет, рано или поздно наступит такой момент, когда либо нужно будет всё обновить, либо вайпнуть :)

Помимо этого если мы идём по пути обновления надо всегда закладывать в архитектуру проекта проверку версий. И тут есть два подхода. Для богатых "поддерживать Х версий проекта и контента" или говорить пользователю "иди обновляйся". Вторым путём скажем идёт близзард в своём Hearthstone. Поэтому до релиза в сторы, если у вас контент хранится на бекенде, всегда закладывать в архитектуру небольшой скриптик. Который спрашивает у сервера "а совместимая ли у меня версия с текущим контентом?" И если нет, то вызывает попап "иди обновись в стор". Это сэкономит вам кучу нервов и времени)

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

Каждому разработчику лучше знать Python

Да и в целом знать несколько языков. Современная разработка позволяет дружить очень много вещей между собой. В той же юнити тоже видно много всяких технологий типа Node.js, так как под тем же десктопов всё супер. Благодаря виртуализации, WSL и докеру в целом можно запускать кучу всяких готовых технологий штук. Но почему именно питон?

Так сложилось, что из-за своей "простоты" на питоне написано столько всего, что там можно закопаться сколько полезного можно встроить в свой проект или пайплайн. https://github.com/wo1fsea/PyTexturePacker как пример

Так же полезно бывает уметь написать собственный простой веб-сервер с помощью Flask с какими-то mock ответами для тестирования. Обработка изображений, перепаковка, чистка проекта по юнити мете. Задач которые удобнее решать питоном очень много. Особенно в рамках винды/линукса, так как никто не мешает запускать Python скрипты из редактора)

Хотя конечно чтобы быть на самом деле "кроссплатформенным разработчиком" в Unity надо знать очень много. Чтобы хорошо работать с Unity WegGL — по хорошему нужно знать js и webpack, Android — Java хотя бы на базовом уровне, IOS — ObjectC/Swift. В идеале для ряда вещей ещё неплохо бы знать на базовом уровне C++ :)

Допустим с тем же WebGL, чтобы научиться грамотно строить работу приложения мне пришлось изучить React.js, хотя бы на среднем уровне, чтобы банально делать правильно "игровой интерфейс". Потому что Unity + WebGL на мобильных платформах имеет кучу проблем в части инпутфилдов, да и не только :) Да и грузится юнити на мобилках, даже если подрезать всё и вся не за 1 секунду) Поэтому лучше в натив выносить всякие "авторизации" и прочее, а игру грузить оффскрин, чтобы пользователь был "занят делом", пока оно грузится, а не смотрел 30 секунд на прогресс бар)

Поэтому не очень хорошо замыкаться в рамках только одного языка и одной технологии. В случае тех же выставок Python вообще must-have, так как если работать с компьютерным зрением, системами трекинга и по счастью вам доступен именно ПК, то OpenCVForUnity и прочие C# решения не сравняться с тем, что есть на Python :) Миллиард всяких полезных тулзов, туториалов (да их можно портировать на шарпы, но это обычно дело не быстрое) и т.п.

Я думаю можно будет побольше пописать про CV и технологии трекинга, так как с помощью них помимо "прикольных интерактивов", можно писать ещё и интересные продакшен тулзы. Та же комбинация IKinema Orion + HTC Vive была когда-то самым дешёвым Motion Capture из возможных) И с неплохим качеством) А потом эпл купил IKinema и нет больше Ориона :)

Лучше писать меньше кода, чем больше

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

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

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

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

2. В них есть баги — и когда это критический баг, а либа решает очень много, нужно придумать воркэраунд. А для этого опять таки мы лезем в исходники либы и смотрим: "писать свой форк" — для опенсорсных, "придумать как обойти" — для закрытых либ, но декомпилируемых. Допустим вот в том же ARFoundation. Казалось бы готовая либа для AR, но у меня есть несколько расширений для неё так как: события на Android и IOS работают по разному и для этого нужен обработчик; в них есть часть багов для которых нужны воркэраунды; они немного по разному работают в разных условиях. Поэтому сделать большое AR приложение — это не просто интегрировать ARFoundation по туториалам и радоваться жизни, там есть огромное количество контекста, которые я продолжаю узнавать. Типа нюансов и проблем динамической подгрузке AR маркеров из облака. (Что такое AR маркер можно тут почитать)

3. Дружить библиотеки с друг другом — нетривиальная архитектурная задача. У каждой библиотеки свой контекст, своя идеология, свои баги, своя частота обновлений. И в рамках проекта интегрировать множество библиотек — уметь надо)

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

Современная разработка. Разработчик и библиотеки

К прошлому посту так сказать :)

Если кому-то интересно, то посмотреть можно тут)

Urban Ekb https://liveapp.onelink.me/V9Nw/hu5l1kvx
Urban Saint-P https://liveapp.onelink.me/V9Nw/tp36joqx

Красота математики

Конечно же математика не так нужна в решении средних задач программиста, но иногда она позволяет творить откровенную и не очевидную «магию»)

Я обожаю интересные задачи математики, в них можно найти очень интересные мысли и подходы, которые довольно неочевидны. Сегодня я наткнулся на любопытное видео. И действительно, очень крутая задача показывающая не очевидную математическую «магию». По сути на основе этой же задачи можно строить алгоритмы поиска скажем по связанным данным. Так как если данные связаны подобным образом, что обладают структурой циклов внутри себя, то это может значительно ускорить поиск в отличии от тех же жадных алгоритмов или алгоритмов поиска, которые работают за log(n) Так как нам не потребуется проходить по всем объектам) А можно предположить, что если наши данные представляют кучу несвязанных циклов, то с некоторой вероятностью сложность поиска будет уже пусть даже линейной, но по циклам меньше, чем log(n).

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

Такими задачами конечно в среднем не занимаются разработчики, но это всё равно безумно интересно. Так же, как меня когда-то впечатлила идея qsort с двумя нодами. Идея в том, что в алгоритмах часто не обращают внимания на то, что сложность O(log(n)) в целом можно грубо развернуть в N * log(n) + C. Где N и C — это какие-то числа. И когда условный поиск/сортировка идёт по миллионам данных, то N=2 и N=1 — это два разительно отличающихся времени поиска)

Конечно я всё ещё считаю, что математика и алгоритмика в современном программировании обязательными не являются, так как в реальности такие задачи — это дай бог 2% задач. И есть много задач вообще не требующих математики) Но в любом случае это очень крутой инструмент :)

Интересный репозиторий с инверсной кинематикой https://github.com/ehsan-mohammadi/Aim-IK

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

Фундаментальные знания

И снова пост из разряда "размышлений на тему". В любой области есть такая проблема, что знания могут стать не актуальны и невостребованными рынком. Технологии умирают, что-то устаревает и т.п. Юнити пока это конечно не грозит, но думаю что когда кто-то начинал изучать Action Script 3 и подумать не мог, что его убьёт HTML5 (но это не значит, что за убийства флеша можно простить! Помним! Скорбим! Не простим!) Поэтому работа в IT это путь постоянного обучения. При этом очень важно актуализировать знания. И где-то тут по тексту мне уже кажется должна быть реклама какого-то курса, но нет) Да и я не хочу пока в этом канале рекламу делать XD

Есть одна абсолютно не устаревающая вещь. Фундаментальные знания. Почему любой Senior разработчик в среднем легко сможет перескочить с технологии Х, на технологию Y? Будет плеваться конечно, но перескочит) Потому что в программировании суть везде одна, меняется чуть-чуть синтаксис, где-то инструменты удобнее (привет джавистам от .Net разрабов), где-то чуть сложнее, так как придётся вникнуть в другую парадигму. Но всё программирование по сути сводится к простой фразе. Программирование — это превращение одного представления данных в другое представление данных посредством серии обработок :) И так по сути можно описать любую программу. Поэтому фундаментальные вопросы архитектуры, простоты, чистоты кода не меняются в зависимости от технологии. И лучше учить их, чем конкретику фреймворков. Конкретику и нюансы фреймворка надо знать только в том фреймворке, в котором ты работаешь. Я просто встречал ребят которые знают миллиард фреймворков, но по сути про программирование не знают ничего (а тут стоит передать привет части фронтендеров)

Чем же прикольны вузовские знания? Многие говорят, что они устарели, что то что проходят в вузах уже не нужно в реальности, так как технологии обновляются быстрее, чем университетские программы. И это так) Но лишь наполовину. Если брать конкретные прикладные технологии, конкретные языки и т.п. в вузе иногда преподаётся что-то древнее. У когда я учился у нас преподавали: C++ — который в целом ой как не скоро можно будет назвать "устаревшим", но у нас преподавали какой-то древний стандарт), Ассемблер — который полезно знать для понимания работы ПК и больше ни за чем и собственно Action Script 3. Но помимо прочего на парах рассказывали про ООП (который не меняется уже хз сколько лет концептуально), про паттерны, про классы, объекты и т.п. И да, конечно я понимаю что можно было в курсе сделать лучше, спустя 10 лет программирования, но оглядываясь назад по той же теории баз данных и прочим вещам нам давали неплохую фундаменталку. Так как ну модель OSI и теорема CAP так же особо сильно не меняются со временем)

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

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

Стоят студенты и курят. И у них спрашивают:
- Hу как, мужики, за сколько сможете китайский выучить?
(Студенты) - А методичка есть?
- Да, есть.
(Студенты) - Hу сейчас докурим и сдадим!

Туториал по симпатичному дождю в 2д в Unity. Просто и со вкусом по сути по работе с партикл системой )

https://www.youtube.com/watch?v=fpGMz5Ia0XM

Классный репозиторий по переводу glsl шейдеров в shaderlab юнити :) Работает не идеально и пишет прям много лишнего, но упрощает работу по переписыванию до "отрезать лишнее" :) https://github.com/pema99/glsl2hlsl

Советы по работе с префабами в Unity

https://habr.com/ru/post/687416/

Давно я не выпускал статей и вот дошли руки написать о том, о чём больше нельзя молчать! Может кому-то пригодятся мои мысли, соображения, опыт и советы на эту тему :)

Пошумим?

Если вы работаете с графикой, то все виды шумов должны быть вашими лучшими друзьями. Я делал очень много различных эффектов основываясь чисто на шуме перлина. По этой причине очень важно напомнить про keijiro сана и про его репозиторий, который лежит теперь удобно пакетом в registry https://github.com/keijiro/NoiseShader

Рекомендую добавить себе в закладки, запомнить что он есть и пользоваться. Волны делаются шумом, прикольные абстрактные формы делаются шумом. Надеюсь скоро наконец-таки зарелизится один проект, и я смогу показать какую ещё симпатичную штуку можно сделать с помощью шума. Как пример интересных работ, как шумом перлина дистортится пламя https://www.graphicon.ru/html/2008/proceedings/English/S8/Paper_3.pdf :) В общем если заниматься VFX в шуме лучше разбираться)

Вообще надо всё же собраться с силами и написать большую обзорную статью про шум и его применения. Так сказать с чем его готовят) Но сейчас пока и так слишком много дел на сентябрь)

Значит хотел с утра начать писать систему для визуализации графов для статьи по графам. Чтобы загрузить какой-то графовый датасет и показать как там можно визуализировать) Оптимизации и т.п. С демкой в WebGL)

Но сделать же нужно нормально, поэтому я закопался в рефлексию и парсинг CSV с ней. Чтобы система не была заточена прям под конкретный граф, то пришлось написать конструкцию, как на скрине, чтобы элегантно пробрасывать маппинги) Видимо статья будет ещё про подходы к асинхронности на вебгл (такси там юзать as is нельзя, проще на корутинах делать) и ещё примером того, как можно обращаться с рефлексией) Ну либо надо будет один репозиторий использовать, как иллюстрацию для пары статей/постов, когда я допишу этого монстра)

Начал я с утра писать проект по графам XD