Это нормально чего-то не знать и чем приколен фриланс

Большой бич современной разработки — это синдром самозванца. Появляется он по логичным причинам. Вот вы несколько лет в разработке, и вам платят действительно много денег, рост обычно очень быстрый. Думаю ни для кого не секрет (да простит меня HR) в целом в современном рынке выгодно хотя бы раз в год менять работу. Если вы не попали на работу мечты, то раз в год меняя работу вы будете в расти в разы быстрее, чем сидя на одном месте. На одном и том же месте вам почти никогда не дадут такого же повышения, как при смене места работы (речь конечно же про разработчиков)

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

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

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

Приезжает мастер чинить конвеер и говорит: "Починка 5500р". Ему говорят "Ок". Он дёргает один рубильник и всё работает. Очевидный вопрос "За что 5500?". "Ну 500р за то, что я приехал, а 5000р за то что я знал какой рычаг дёрнуть" :)

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

Для грамотной работы с графикой в целом лучше понимать хотя бы на поверхностном уровне информацию из арт дисциплин. И одна из самых интересных вещей — это цвет. Она то и с технической части достаточно любопытна (цветовые пространства и т.п.) Нашёл вот интересный урок по теории цвета https://youtu.be/NH1TLyiJVHU

Проблема профессионалов

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

С точки зрения профессионала многие вещи кажутся элементарными, и смысл о них говорить? Помню я когда-то хотел написать простенький локальный мультиплеер. И p2p, Nat звучало очень сложными словами. Так как для того, чтобы понять как это сделать нужно обладать терминологией и знать всего лишь одно определение STUN сервер. Да что тут говорить вообще, самая популярная статья на хабре за всё время из моих, это по сути документация Unity Event System переписанная русским языком с примерами https://habr.com/ru/post/359106/ :)

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

Опасности опенсорса

Это весьма любопытно, но многие недооценивают опасности опираться на облачные репозитории. Вот сегодня меня удивили юнити, что у них по сути нет своего репозитория с версиями нужных им пакетов https://forum.unity.com/threads/unity-hub-3-1-release-overview.1253823/

В чём суть. Один из контрибьюторов одного из опенсорс пакетов node-ipc внёс в него по сути вредоносную функциональность. Unity Hub использует этот пакет и по сути доставил всем пользователям хаба вредоносное ПО позволяющее писать файлы в системе, что очень опасно. Думаю сейчас у всех этот пакет должен просто попасть в чёрный список, но интересно вот что. Это показательный пример почему тех директора должны объяснять бизнесу «зачем нам своя копия необходимых нам библиотек и свои репозитории». Так как представим у вас завтра релиз, вы обновили хаб (зачем-то) и потеряли все данные. Пусть даже у любого здравого человека сейчас есть бекапы, это трата времени и нервов в итак не самый спокойный день. А если это не хаб, а скажем серверное ПО, то это просто доставка угрозы в ваше облако без смс и переплат

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

Жаль, но видимо Project Tiny всё

Кто не в курсе у юнити был такой замечательный проект, как Project Tiny. Он идеологически должен был позволять делать маленькие легковесные игры, playable ads и т.п. Всё по красоте на DOTS с ECS. Если вы хоть раз связывались с Unity WebGL то вы в курсе насколько он прожорливый и тяжеловестный. Когда-то для совсем небольшого проекта я делал простенькую веб админку (в те времена веб технологии я ещё не знал, поэтому такой экстравагантный выбор) И простенькая админка с парой кнопок и простым UI заставляло мой тогдашний макбук про взлетать. Помимо скорости загрузки, так как только позже я узнал, что в веб гл вообще все ресурсы (кроме базового UI) выносить в ассет бандлы, иначе грузится оно просто вечность)

Хотя официальных заявлений на эту тему я так и не нашёл, но видимо Unity забили на Project Tiny, что очень жаль. Концепт был довольно интересный. Делать легковесный веб на юнити — кайф же. Но в последних версиях Unity его уже даже нет в превью пакетах https://docs.unity3d.com/Packages/com.unity.tiny@0.16/manual/index.html

Чтож, придётся делать веб игры на three или babylon js. Хотя конечно сейчас когда я уже пару недель разбираюсь с pixi и three можно сказать одно. Давно я не писал столько кода, всё же на сколько визуальный редактор и компонентная систему упрощает процесс разработки

Решил ещё на всякий подключить Дзен, вдруг кому-то там читать будет удобнее :) https://zen.yandex.ru/id/6235ce8fe9c353590fd97c06

Плюс любопытная штука, что яндекс сделал бота, который автоматически переносит посты из телеграма в дзен. Посмотрим, как оно работает. Пока сам дзен работает довольно странно по UX с точки зрения автора :) Но если бот сам всё будет переносить, то почему бы и нет :)

Полезная и интересная статья про текстуры и виды текстурных карт. В особенности для начинающих https://dtf.ru/gamedev/1113705-plotnost-tekseley-i-nemnogo-teorii-tekstur-ot-entoni-o-donnella?from=rss

Немного мыслей про заклинания и UX

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

И они довольно неплохи, но выглядят скорее как недоделанный WoW. И я заметил одну мелкую недоработку. Я начал играть за метаморфа и почти все спеллы, на низких уровнях по крайней мере, работают странно. При построении любого заклинания с точки зрения игры есть 3 фазы, как оно по хорошему должно работать. Запуск, полёт и попадание. И попадание должно быть:

1) Достаточно ярким
2) Синхронизировано с получением урона
3) Синхронизировано с отлетающим текстам

А в Аллодах это почему-то воспринимается не так. При использовании любого заклинания урон воспринимается как-то странно, то ли он срабатывает раньше, то ли позже. Любопытная мелочь, так как в вове в этом плане всё сделано ювелирно. Даже АОЕ спеллы попавшие в цель всегда имеют выразительный и понятный визуальный отклик

Иногда нужно разминаться

Программирование штука комплексная, в которой очень много различных задач. Но в конечном итоге, хотя математика в программировании не обязательное, но очень полезная штука, у разработки и математики есть одно сходство. Проще всего развиваться через практику. Чем больше пишешь кода, тем проще тебе его писать дальше. Так как многие задачи становятся типовыми на уровне "да я 150 раз это делал". И чем больше разного делаешь, тем больше таких задач)

Например написание игрового ИИ и ботов. Да, есть много всяких книжек, где объясняются концепции Behavior Tree или FSM, но чтобы попрактиковаться в написании ИИ в том же юнити — нужно сначала написать игру, и целую систему. Не лучший подход для получения практики. Я периодически люблю для разминки играть в эту штуку: https://www.codingame.com/ Это прикольная платформа с интерактивными заданиями. ИИ это один из моих любимых видов контестов. Так же, как есть всякие пазлы, оптимизации и многое другое на самых разных языках программирования. И шарп тоже есть. И для разминки штука вообще замечательная. Не думаешь про архитектуру, про систему, просто решаешь выделенные задачки и практикуешься :) И главное — он весёлый, так как у игр тут есть графика и т.п.

Можно было бы вспомнить https://codeforces.com/ но для меня он больше олимпиадный для разработчиков олимпиадников, что тоже классно, но мягко говоря в коммерции не всегда нужно и важно. Так как большинство программистов и Кнута то не читали в наши дни :) И главная проблема кодфорсес — он скучный, хотя он и не задумывался, чтобы быть весёлым :)

Вот как пример одной из игр — гоночки, с которой я раньше любил играться. Хотя до ума я там его и не довёл, болтаюсь где-то на 19 тысячном месте в рейтинге :) https://www.codingame.com/replay/603073981

Новый супер красивый ролик от Unity. Волосы просто кайф :) И огонь хорош) https://youtu.be/eXYUNrgqWUU

Поговорим про графику

Ну и под такой красивый ролик, как не поговорить про графику :) В целом реалтайм пайплайн — это классный концепт сейчас. Конечно же в сравнении с тем, когда кадры рендерятся по несколько минут. Даже когда кадр рендерится одну минуту, то рендер десяти секунд ролика в 30 фпс превращается в 5 часов. Ну и в целом хорошая графика зависит лишь от проработки материалов, системы освещения и т.п.

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

Да, если по этому ролику ещё пока сампл не выложен, но у Unity есть пакет Digital Human (про который многие не знают) Где есть интересные шейдеры кожи, волос, зубов и т.п. https://github.com/Unity-Technologies/com.unity.demoteam.digital-human

И есть более менее разобранный пример с Heretic

Обожаю эти выступления. Это довольно старое, но что материал, что подача конечно отличные)

Ну и показывает интересные приколы и фишки юнити :) С точки зрения перфоманса https://youtu.be/W45-fsnPhJY

Новый прикольный шоурил от юнити, показывающий разнообразие создаваемых проектов на движке https://youtu.be/c90KRdMz1zw

В целом даже завораживающе, сколько совершенно разных проектов делается в мире, разными командами с разными подходами и уровнями :) Всегда любил наблюдать за разными инди проектами :)

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

Но хоть в этом докладе поднимается тема бенчмарков, я считаю что он полезен всем чисто для общего образования в плане понимания работы процессора, памяти и т.п. https://youtu.be/XGtieBVI1lk Как и в целом многие другие доклады Андрея Акиньшина по дотнету. Я бы правда сказал, это такое знание не которым надо прям пользоваться, но о котором в общих чертах надо помнить. Так как реальная применимость этого — редкая, но знать о том, что такое есть — очень важно, так как это расширяет понимание работы с дотнетом, кодом и т.п.

Профессионал и ремесленник

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

К чему это я? Можно оставаться ремесленником, всегда как бы и кусок хлеба будет, и к чаю чего-нибудь. Но что отличает в основном профессионала от ремесленника? Для меня это набор пунктов:

1. Понимание того, что бесполезных знаний не существует — да, это может быть ненужно прямо здесь и сейчас, но чем больше ты знаешь, тем больше у тебя инструментов
2. Большая ориентация на фундаметальные знания — знать много частностей рабочий вариант и это классно, но как в любой области обычно эти частности объединяет общий фундамент. И знания фундамента получается всегда более универсальным
3. Знание большого числа технологий. И вот тут важно зачем. Когда ты понимаешь сетевые технологии, понимаешь веб технологии и т.п. — ты по-настоящему можешь писать кроссплатформенно и что угодно. И тебе проще, так как ты понимаешь всегда другую сторону. Неважно чем ты занимаешься бекендом, фронтендом или чем-то ещё

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

#рекомендация #литература

Кстати, по части в целом работы с сетью могу порекомендовать книгу "Многопользовательские игры. Разработка сетевых приложений | Глейзер Джошуа, Мадхав Санджай". Она отлично объясняет устройство модели OSI, разные архитектуры сети и тому подобное. И просто в деталях рассказывает низкий уровень устройства сети и каким образом строятся различные мултиплеерные игры :) Очень советую всем прочесть :) Отличная книга)