Если коротко, очень зависит от игры. Описанный кейс вероятно будет решать реакт разработчик вообще. Так как весь гуй на стороне реакта)
Такой процесс и подход предполагает, что все проблемы гуя решаются на стороне реакта. А на стороне юнити нужно один раз написать апи для проброса нужных параметров
Смотря о чём речь. Если юнити - геймплейный плеер. Весь мета гейм вероятно будет на стороне реакта, и тут надо смотреть в частностях. Отображение счёта или валют, или чего-то ещё можно делать на уровне логов. Простые кнопки, моки и команды решают остальное. Там не нужен гуй. Дублирование гуя слишком дорогой инструмент получится с его поддержкой. Контекст меню юнити, хоткеи и т.п. Полный цикл уже в билде, так как тестирует не разработчик, а тестер.
И тут вопрос, что такое долго. Если билд собирается билд роботом, то не особо дольше, чем il2cpp сборки. Юнит тесты скажем так через гуй и при обычной работе не стоит делать.
Особняком тут будут ММО или рпг, где сложный интерфейс сопряжён автоматом с геймплеем. Но всё равно тестить смотря что и смотря как. Если настроены ассембли, если правильно организован с разбивкой ассетов на бандлы, то пересборки просто будут не такими частыми)
Смотрите. Я безо всякого, просто правда не понял суть вопроса :) Не совсем. Префаб GameObject лишь с точки зрения кода, а с точки зрения конфига нет. Так как он сериализует все параметры висящих на нём компонент и т.п. ViewModel же осуществляет биндинг этих данных в код для проброса грубо говоря, как в том же самом xaml в UWP. Ну то есть GameObject — это бидинг по сути, как мы из кода обращаемся к конфигу. Так как он (конфиг) хранит все параметры и все ссылки на компоненты. Так как с точки зрения самого кода можно пойти ещё глубже до понятия самого скелетного скелета в Unity, это UnityEngine.Object, который обобщает вообще все виды объектов в редакторе.
Ну то есть если вы откроете именно файл с расширением .prefab, там же будут не только данные о трансформе, но и ссылки на все компоненты и что важно их параметры. Поэтому .prefab != GameObject. Класс GameObject можно воспринимать как удобный биндинг, который позволяет из кода навигироваться по ViewModel, задавая View более сложные поведения. Но View он не является. На примере пользовательского интерфейса, ViewModel — это Transform, Image, Button, TMP_Text. Если расписывать в целом схему, то GameObject опять таки тут будет обобщающим биндингом для доступа к этим компонентам, которые являются визуальной частью биднящую параметры отрисовки к модулю рендера, то есть той же ViewModel. И тут даже нет конфликта логики, так как View всё ещё остаются параметры записанные в виде текста (ну или бинарной информации) в файл .prefab. Проще всего это понимать просто через UWP и xaml, так как по сути там всё немного прозрачнее. Тут просто Unity текстовый конфиг заменило на решение в котором во главе стоит визуальный редактор)
Это просто иллюстрация к тому, что не надо забивать на то, как организовано View, что в проектах я вижу слишком часто) Некоторые не пользуются префабами как View) И пишут в стиле андроид разработки без XML :) Чисто code-first интерфейсы. А есть такой подход где наследники SO — это модель, компоненты наследники Monobehavior — это View-Model, а префабы — View. Получается стиль почти написания UWP приложений. Ток на других форматах :)
Наследник Monobehaviour навешиваемый на GO — это и есть компонент в данном контексте. И можно писать в таком стиле, что данные компоненты будут View-Model. Можно писать в другом стиле. Я скорее не понял суть вопроса :) Есть такой стиль архитектуры для проекта. Это не раскрывается, потому что как в юнити пишутся разные архитектурные схемы, почему любой крупный проект это всегда гибрид, и где лучше реактивный подход, а где другой — это не тема статьи :)
Брать джунов и мидлов нужно только затем, что нужны новые сеньоры. Иначе скоро один сеньор будет стоить, как крыло от боинга (хотя я не скажу, что я против) :) В остальном в 99% случаев - это расход ресурсов и денег :) Сеньоры делают быстрее всё. И рутину, и сложные задачи. Что рутину часто впадлу делать - это другой вопрос. Но когда ты задачу решал 150 раз, то в 151 ты делаешь её примерно за минуту. Сеньорам есть что обсудить на ревью, и часто сеньорам лень менять компанию, так как денег платят везде на определённом уровне в тех же корпах +- одинаково. И если ты уже "устал от приключений", ты просто работаешь на проекте и не паришься. Чаще всего мотивацией смены работы я видел скуку, а не вопрос деньгах. Лидами вообще многие становится в принципе не хотят.
В большинстве своём сеньоры - это такие бывалые, уставшие профессионалы, которым плевать что делать, так как они умеют очень многое и на контекст задачи смотрят, как на предметную область. Бывает кто-то ещё горит работой, но за 6 лет+ ты начинаешь к программированию (коммерческому) относится филосовски. Пилишь какой-то пет проектик, если тебе не надоело программировать, так как там никто не меняет бизнес требования, не переобувается на лету, не нужно думать о коммерческих рисках использования той или иной технологии. А коммерция вся +- одна и та же, меняется по моему опыту разве что контекст. Поэтому нет смысла менять особо компанию, так как поменяешь в большинстве случаев одно на другое, если не подвернётся действительно супер интересный проект :)
Ну с компьютами в рядах случаев удобнее работать именно в графе. Но тут есть несколько нюансов. Я очень долго был старовером не пользующимся нодовыми редакторами, но сейчас я возможностью делать кастом ноды я больше склоняюсь к ним. И тут есть свои плюсы и минусы в одном флаконе
1. Высокий уровень абстракции может оптимизироваться автоматически
Шейдеры написанные на glsl и hlsl нельзя оптимизировать компилятором, так как это довольно чёткие инструкции о том, что надо сделать. А вот графы проще оптимизировать, проще подсовывать им реализации под VR с сингл пасс стерео рендером, так как это условно "логическое описание, а не чёткая инструкция". Но как обратная сторона любой абстракции высокого уровня, её нельзя тонко настраивать и зная юнитеков, если там будут баги - это может стать проблемой
2. Дебаг шейдеров
Чуть быстрее процесс редактирования, чуть проще организовать пере использование, но при этом ещё каждый шаг может иметь визуальный вывод, что оно делает. И вот последним шейдерный код не обладает. Типа нужно удалять куски, писать какие-то утилиты, чтобы иметь пошаговый вывод, чтобы проще было дебагать шейдер
В общем кодом я так же шейдеры пишу, но сейчас я пишу и так, и так. Просто если не требуется прям до спичек оптимизировать - графы норм. Если нужно сначала за прототипировать, описать сам эффект, глянуть его, а потом уже переписать нормально - граф в среднем будет быстрее с точки зрения "попробовать разное". А когда сам шейдер идейно готов, уже можно написать оптимально, если вдруг тормозит.
Пил пол года XD А так хз, я просто что называется "на своём месте". Выгорание у меня обычно связано со стрессом бизнеса, а не с работой. Кассовые разрывы (я терпеть не могу кому-то задерживать выплаты, но деньги из воздуха тоже пока не умею делать) и тому подобное, иногда груз ответственности
А сидеть и чё-то делать по работе я могу просто сутками и по сути не уставать. Так как это интересно)
Я скажу так. Да, название немного кликбейтное. Но по студии в чём история.
3 года она зарабатывала, не скажу что много, но на зарплаты и т.п. хватало и себе тоже. Потом я сделал ставку на конгрессно-выставочную индустрию в начале 2019 года. И тут пандемия грянула. В целом и это можно было пережить. Но я тогда уже выгорел быть постоянно в стрессе и ритме вечной работы. Выплатил всем сотрудникам доп. оклад, распустил команду, и ушёл на пол года в консалт. Так как на данный момент я один из людей разбирающихся в технологиях трекинга. Не единственный, но таких немного на вольных хлебах. От OpenCV до Vicon и Optitrack. Я перечитал очень много статей научных, делал прототипов и в целом работал с этой группой технологий последние 6 лет + учился всякому у трекинг инженеров вайкона.
Согласен. Тут важно только не столько "что значит техдир", а в том числе в какой индустрии. Я работаю В AR/VR и интерактивных визуализациях. Поэтому по моей терминологии техдир в данной индустрии, это человек который может: 1. Составить роадмап разработки продукта в данной области 2. Составить технологический стек и его обоснование, причём коммерческое 3. Составить смету на роадмап (хотя бы на пол года), понимать какой нужен штат для реализации проекта с технической точки зрения 4. Составить техническую схему решения. С оборудованием и прочими прелестями жизни. Зная какая железка лучше и почему 5. Иметь опыт реализации подобного класса проектов
И да техдир - это больше менеджер, чем технарь. Я разбираюсь в Unity, в .Net, в нюансах процессоров (кешлайн сплит, выравнивание памяти) в основном по мануалам интела, компьютерной графике (можно почитать мои статьи и мой блог), математике (когда-то давно я занимался математическим моделированием), технологиях трекинга и так далее. И в некоторых вещах я разбираюсь достаточно глубоко, так как считаю, что фундаментальные знания важнее практических. И типа по графике вот пример поста, где я по-русски пытался объяснить низкоуровневый нюанс работы гпу в паре с шиной https://t.me/dyadichenkoga/206 И докер разверну, и шел скрипт напишу. Ещё я очень поверхностно знаю реакт, питон. И прям чуть-чуть плюсы. Читать и портировать смогу, писать на нём - очень сложно и это делают какие-то ниндзя. Я конечно помню смарт поинтеры и частично 11 стандарт, но как писать быстрый код на плюсах я не знаю. Чистая архитектура, солид и т.п. У меня в целом в блоге есть разбор паттернов в контексте Unity. TCP/IP, RSTP, WebRTC и т.п. С этим всем я тоже работал, писал кастомные протоколы стриминга и много чего ещё. Но просто это в плане техдирства, особенно глубокие задачи решать, не так важно. Так как это будут делать сеньоры, которые разбираются лучше.
И вот тут может показаться уже, что я хвастаюсь. Но я также могу хвастаться числом статей, выступлениями, то что я организовывал мероприятия на 200+ человек для разработчиков, да хоть репозиториями со звёздочками (хотя там вообще ничего великого, по-моему мнению) И вот это на мой взгляд будет странно. А в статье я просто рассказал, какой путь на данный момент прошёл.
И всё это небольшая индустрия. Я конечно же не говорю, что "да ща я техдиром Яндекса стану". Но отличие техдира от техлида в том, что он знает широкий спектр технологий и может построить команду и довести её до финала в сложном интеграционном проекте. С беком, фронтом и сложными технологиями. А не в рамках узкого стека технологий. Так как техлиды часто разбираются в своём стеке (хотя тоже бывают разные) Поэтому я ушёл в "продюсирование проектов на заказ" с подбором команды под проект, и работаю сам по себе.
Просто безусловно существуют разные масштабы команд, компаний и т.п. Я ща на вольных хлебах и консультирую часть компаний и стартапов. Просто писал я немного не о том.
Выше есть комент про L7+ FAANG, и с ним я согласен за исключением одного нюанса. Это всё оптимальная стратегия, когда ты хотя бы номинально сеньор. Я же писал скорее про путь джун-сеньор. С позиции сеньора варианты развития в разы разнообразнее, сложнее и интереснее. А проходить так участок пути джун-сеньор - оптимальнее.
Любой работодатель знает, что хай левел сотрудник начинает приносить прибыль минимум через полгода. С моим зарплатным запросом если я уйду после испытательного, я просто потрачу деньги компании. В чём я не вижу смысла, а уходить на испытательном, если мне не подходит работа — нормальная практика.
Это та позиция, которую мне предлагают. В студии я отвечал не только за техническую часть, но это особо значения не имеет) В студии — это была моя компания)
Скучно не технически, а по спектру обязанностей. А на сеньора мне нет идти смысла из-за текущего дохода даже в теории. И свои обязательства перед заказчиками я соблюдаю вне зависимости от интереса. Вы считали какой-то не тот посыл :)
Я не пойду на работу, так как мне не особо это интересно, а не то, что я технически узнал всё что можно было.
Я просто трудоголик. У меня был свой митап Unity Moscow Meetup и CGDevs, я основатель http://gamedev-calendar.ru/, 28 статей на хабре, пара выступлений (как пример https://www.youtube.com/watch?v=GUhs-emib_8 ) и много чего ещё. А так я просто рано начал работать, по сути 8 лет назад. И с тех пор работаю сутками. Плюс везло очень много, особенно с теми, кто мне по ходу что-то объяснял :)
Ну сводно всю инфу я тут собрал https://noxatra.ru/ чё я делал за последние годы. А так, работа и везение. Ну и маховик времени конечно же :)
Дак я прогорел в своё время. У меня была своя студия, которую я закрыл не от хорошей жизни) Был неопытный, совершил много ошибок, но добила меня пандемия. Так что согласен, но просто я наверное опустил ряд деталей про которые можно рассказать. Закрывал я студию, не как успешный кейс с чемоданом денег, а с минусом в несколько миллионов рублей. И этот минус я разгребал ещё пару лет.
Тут может показаться, что это история успеха, так как я в целом всегда на позитиве. Но на самом деле — это просто история на данный момент, и всё ещё впереди :) И деятельность моя текущая не всем подойдёт, она тоже имеет свои скажем так особенности. Но карьерные советы рабочие, так как просто я понимаю с разных точек зрения как сейчас устроен рынок найма.
У меня ща конечно всё норм, есть свой продукт небольшой и куча всяких дел. Но так как я уже разорялся, я знаю что и сейчас хожу "по ох***но тонкому льду" и что всегда нужно держать руку на пульсе. Но в любом случае спасибо, всегда интересно послушать мнение со стороны :)
В статье просто небольшая опечатка. Сейчас поправлю 65535 конечно же. Откуда? Достаточно посмотреть структуру пакета TCP. И порт там занимает 16 бит. 2^16-1 = 65535. Но всё ещё не понимаю реакцию, так как это явно опечатка
Ну я даже немного распространю. Плохое соединение на выставках - это скорее не перегружен траффик, а радиошум. Так как много железа, телефонов и другого оборудования. Можно решить 100% - дорогим оборудованием, но с обычным тут могут быть риски задержек. Причём весьма высоких. Но эту проблему можно решить только шнуром. Потому что там и персистент коннект не спасёт, так как оборудование банально пингуется долго. Поэтому обычно когда такая штука разворачивается, ставятся специфичные условия. Хотя бы приличный роутер :)
Но геймпад это один пример применения вшитого http сервера. Есть геймплеи где задержка нажатия в 1 секунду не играет вообще никакой роли. Иногда нужно администрировать Unity приложения, которые вообще не игры. И удобнее это делать с планшетов. Но при этом с точки зрения апдейта и деплоя в разы проще просто обновлять контейнер на сервере в котором и веб лежит.
Да вы правы. Это можно немного решить, если поддержать Keep-Alive, но в общем да. Тут скорее "нет смысла в контексте рассматриваемых условий". А я рассматриваю условия "хорошие". В среднем сейчас слабый сервер, как контекст, скорее редкость, а вот плохое соединение может сыграть роль
Если коротко, очень зависит от игры. Описанный кейс вероятно будет решать реакт разработчик вообще. Так как весь гуй на стороне реакта)
Такой процесс и подход предполагает, что все проблемы гуя решаются на стороне реакта. А на стороне юнити нужно один раз написать апи для проброса нужных параметров
Смотря о чём речь. Если юнити - геймплейный плеер. Весь мета гейм вероятно будет на стороне реакта, и тут надо смотреть в частностях. Отображение счёта или валют, или чего-то ещё можно делать на уровне логов. Простые кнопки, моки и команды решают остальное. Там не нужен гуй. Дублирование гуя слишком дорогой инструмент получится с его поддержкой. Контекст меню юнити, хоткеи и т.п. Полный цикл уже в билде, так как тестирует не разработчик, а тестер.
И тут вопрос, что такое долго. Если билд собирается билд роботом, то не особо дольше, чем il2cpp сборки. Юнит тесты скажем так через гуй и при обычной работе не стоит делать.
Особняком тут будут ММО или рпг, где сложный интерфейс сопряжён автоматом с геймплеем. Но всё равно тестить смотря что и смотря как. Если настроены ассембли, если правильно организован с разбивкой ассетов на бандлы, то пересборки просто будут не такими частыми)
Смотрите. Я безо всякого, просто правда не понял суть вопроса :) Не совсем. Префаб GameObject лишь с точки зрения кода, а с точки зрения конфига нет. Так как он сериализует все параметры висящих на нём компонент и т.п. ViewModel же осуществляет биндинг этих данных в код для проброса грубо говоря, как в том же самом xaml в UWP. Ну то есть GameObject — это бидинг по сути, как мы из кода обращаемся к конфигу. Так как он (конфиг) хранит все параметры и все ссылки на компоненты. Так как с точки зрения самого кода можно пойти ещё глубже до понятия самого скелетного скелета в Unity, это UnityEngine.Object, который обобщает вообще все виды объектов в редакторе.
Ну то есть если вы откроете именно файл с расширением .prefab, там же будут не только данные о трансформе, но и ссылки на все компоненты и что важно их параметры. Поэтому .prefab != GameObject. Класс GameObject можно воспринимать как удобный биндинг, который позволяет из кода навигироваться по ViewModel, задавая View более сложные поведения. Но View он не является. На примере пользовательского интерфейса, ViewModel — это Transform, Image, Button, TMP_Text. Если расписывать в целом схему, то GameObject опять таки тут будет обобщающим биндингом для доступа к этим компонентам, которые являются визуальной частью биднящую параметры отрисовки к модулю рендера, то есть той же ViewModel. И тут даже нет конфликта логики, так как View всё ещё остаются параметры записанные в виде текста (ну или бинарной информации) в файл .prefab. Проще всего это понимать просто через UWP и xaml, так как по сути там всё немного прозрачнее. Тут просто Unity текстовый конфиг заменило на решение в котором во главе стоит визуальный редактор)
Надеюсь понятно объяснил)
Это просто иллюстрация к тому, что не надо забивать на то, как организовано View, что в проектах я вижу слишком часто) Некоторые не пользуются префабами как View) И пишут в стиле андроид разработки без XML :) Чисто code-first интерфейсы. А есть такой подход где наследники SO — это модель, компоненты наследники Monobehavior — это View-Model, а префабы — View. Получается стиль почти написания UWP приложений. Ток на других форматах :)
Наследник Monobehaviour навешиваемый на GO — это и есть компонент в данном контексте. И можно писать в таком стиле, что данные компоненты будут View-Model. Можно писать в другом стиле. Я скорее не понял суть вопроса :) Есть такой стиль архитектуры для проекта. Это не раскрывается, потому что как в юнити пишутся разные архитектурные схемы, почему любой крупный проект это всегда гибрид, и где лучше реактивный подход, а где другой — это не тема статьи :)
Брать джунов и мидлов нужно только затем, что нужны новые сеньоры. Иначе скоро один сеньор будет стоить, как крыло от боинга (хотя я не скажу, что я против) :) В остальном в 99% случаев - это расход ресурсов и денег :) Сеньоры делают быстрее всё. И рутину, и сложные задачи. Что рутину часто впадлу делать - это другой вопрос. Но когда ты задачу решал 150 раз, то в 151 ты делаешь её примерно за минуту. Сеньорам есть что обсудить на ревью, и часто сеньорам лень менять компанию, так как денег платят везде на определённом уровне в тех же корпах +- одинаково. И если ты уже "устал от приключений", ты просто работаешь на проекте и не паришься. Чаще всего мотивацией смены работы я видел скуку, а не вопрос деньгах. Лидами вообще многие становится в принципе не хотят.
В большинстве своём сеньоры - это такие бывалые, уставшие профессионалы, которым плевать что делать, так как они умеют очень многое и на контекст задачи смотрят, как на предметную область. Бывает кто-то ещё горит работой, но за 6 лет+ ты начинаешь к программированию (коммерческому) относится филосовски. Пилишь какой-то пет проектик, если тебе не надоело программировать, так как там никто не меняет бизнес требования, не переобувается на лету, не нужно думать о коммерческих рисках использования той или иной технологии. А коммерция вся +- одна и та же, меняется по моему опыту разве что контекст. Поэтому нет смысла менять особо компанию, так как поменяешь в большинстве случаев одно на другое, если не подвернётся действительно супер интересный проект :)
Ну с компьютами в рядах случаев удобнее работать именно в графе. Но тут есть несколько нюансов. Я очень долго был старовером не пользующимся нодовыми редакторами, но сейчас я возможностью делать кастом ноды я больше склоняюсь к ним. И тут есть свои плюсы и минусы в одном флаконе
1. Высокий уровень абстракции может оптимизироваться автоматически
Шейдеры написанные на glsl и hlsl нельзя оптимизировать компилятором, так как это довольно чёткие инструкции о том, что надо сделать. А вот графы проще оптимизировать, проще подсовывать им реализации под VR с сингл пасс стерео рендером, так как это условно "логическое описание, а не чёткая инструкция". Но как обратная сторона любой абстракции высокого уровня, её нельзя тонко настраивать и зная юнитеков, если там будут баги - это может стать проблемой
2. Дебаг шейдеров
Чуть быстрее процесс редактирования, чуть проще организовать пере использование, но при этом ещё каждый шаг может иметь визуальный вывод, что оно делает. И вот последним шейдерный код не обладает. Типа нужно удалять куски, писать какие-то утилиты, чтобы иметь пошаговый вывод, чтобы проще было дебагать шейдер
В общем кодом я так же шейдеры пишу, но сейчас я пишу и так, и так. Просто если не требуется прям до спичек оптимизировать - графы норм. Если нужно сначала за прототипировать, описать сам эффект, глянуть его, а потом уже переписать нормально - граф в среднем будет быстрее с точки зрения "попробовать разное". А когда сам шейдер идейно готов, уже можно написать оптимально, если вдруг тормозит.
Мне кажется более стандартное решение в виде BSP-дерева было бы лучше, и было бы интересно посмотреть сравнение результатов R*-дерева с ним
Пил пол года XD А так хз, я просто что называется "на своём месте". Выгорание у меня обычно связано со стрессом бизнеса, а не с работой. Кассовые разрывы (я терпеть не могу кому-то задерживать выплаты, но деньги из воздуха тоже пока не умею делать) и тому подобное, иногда груз ответственности
А сидеть и чё-то делать по работе я могу просто сутками и по сути не уставать. Так как это интересно)
Я скажу так. Да, название немного кликбейтное. Но по студии в чём история.
3 года она зарабатывала, не скажу что много, но на зарплаты и т.п. хватало и себе тоже. Потом я сделал ставку на конгрессно-выставочную индустрию в начале 2019 года. И тут пандемия грянула. В целом и это можно было пережить. Но я тогда уже выгорел быть постоянно в стрессе и ритме вечной работы. Выплатил всем сотрудникам доп. оклад, распустил команду, и ушёл на пол года в консалт. Так как на данный момент я один из людей разбирающихся в технологиях трекинга. Не единственный, но таких немного на вольных хлебах. От OpenCV до Vicon и Optitrack. Я перечитал очень много статей научных, делал прототипов и в целом работал с этой группой технологий последние 6 лет + учился всякому у трекинг инженеров вайкона.
Согласен. Тут важно только не столько "что значит техдир", а в том числе в какой индустрии. Я работаю В AR/VR и интерактивных визуализациях. Поэтому по моей терминологии техдир в данной индустрии, это человек который может:
1. Составить роадмап разработки продукта в данной области
2. Составить технологический стек и его обоснование, причём коммерческое
3. Составить смету на роадмап (хотя бы на пол года), понимать какой нужен штат для реализации проекта с технической точки зрения
4. Составить техническую схему решения. С оборудованием и прочими прелестями жизни. Зная какая железка лучше и почему
5. Иметь опыт реализации подобного класса проектов
И да техдир - это больше менеджер, чем технарь. Я разбираюсь в Unity, в .Net, в нюансах процессоров (кешлайн сплит, выравнивание памяти) в основном по мануалам интела, компьютерной графике (можно почитать мои статьи и мой блог), математике (когда-то давно я занимался математическим моделированием), технологиях трекинга и так далее. И в некоторых вещах я разбираюсь достаточно глубоко, так как считаю, что фундаментальные знания важнее практических. И типа по графике вот пример поста, где я по-русски пытался объяснить низкоуровневый нюанс работы гпу в паре с шиной https://t.me/dyadichenkoga/206 И докер разверну, и шел скрипт напишу. Ещё я очень поверхностно знаю реакт, питон. И прям чуть-чуть плюсы. Читать и портировать смогу, писать на нём - очень сложно и это делают какие-то ниндзя. Я конечно помню смарт поинтеры и частично 11 стандарт, но как писать быстрый код на плюсах я не знаю. Чистая архитектура, солид и т.п. У меня в целом в блоге есть разбор паттернов в контексте Unity. TCP/IP, RSTP, WebRTC и т.п. С этим всем я тоже работал, писал кастомные протоколы стриминга и много чего ещё. Но просто это в плане техдирства, особенно глубокие задачи решать, не так важно. Так как это будут делать сеньоры, которые разбираются лучше.
И вот тут может показаться уже, что я хвастаюсь. Но я также могу хвастаться числом статей, выступлениями, то что я организовывал мероприятия на 200+ человек для разработчиков, да хоть репозиториями со звёздочками (хотя там вообще ничего великого, по-моему мнению) И вот это на мой взгляд будет странно. А в статье я просто рассказал, какой путь на данный момент прошёл.
И всё это небольшая индустрия. Я конечно же не говорю, что "да ща я техдиром Яндекса стану". Но отличие техдира от техлида в том, что он знает широкий спектр технологий и может построить команду и довести её до финала в сложном интеграционном проекте. С беком, фронтом и сложными технологиями. А не в рамках узкого стека технологий. Так как техлиды часто разбираются в своём стеке (хотя тоже бывают разные) Поэтому я ушёл в "продюсирование проектов на заказ" с подбором команды под проект, и работаю сам по себе.
Просто безусловно существуют разные масштабы команд, компаний и т.п. Я ща на вольных хлебах и консультирую часть компаний и стартапов. Просто писал я немного не о том.
Выше есть комент про L7+ FAANG, и с ним я согласен за исключением одного нюанса. Это всё оптимальная стратегия, когда ты хотя бы номинально сеньор. Я же писал скорее про путь джун-сеньор. С позиции сеньора варианты развития в разы разнообразнее, сложнее и интереснее. А проходить так участок пути джун-сеньор - оптимальнее.
Любой работодатель знает, что хай левел сотрудник начинает приносить прибыль минимум через полгода. С моим зарплатным запросом если я уйду после испытательного, я просто потрачу деньги компании. В чём я не вижу смысла, а уходить на испытательном, если мне не подходит работа — нормальная практика.
Это та позиция, которую мне предлагают. В студии я отвечал не только за техническую часть, но это особо значения не имеет) В студии — это была моя компания)
Скучно не технически, а по спектру обязанностей. А на сеньора мне нет идти смысла из-за текущего дохода даже в теории. И свои обязательства перед заказчиками я соблюдаю вне зависимости от интереса. Вы считали какой-то не тот посыл :)
Я не пойду на работу, так как мне не особо это интересно, а не то, что я технически узнал всё что можно было.
Я просто трудоголик. У меня был свой митап Unity Moscow Meetup и CGDevs, я основатель http://gamedev-calendar.ru/, 28 статей на хабре, пара выступлений (как пример https://www.youtube.com/watch?v=GUhs-emib_8 ) и много чего ещё. А так я просто рано начал работать, по сути 8 лет назад. И с тех пор работаю сутками. Плюс везло очень много, особенно с теми, кто мне по ходу что-то объяснял :)
Ну сводно всю инфу я тут собрал https://noxatra.ru/ чё я делал за последние годы. А так, работа и везение. Ну и маховик времени конечно же :)
Дак я прогорел в своё время. У меня была своя студия, которую я закрыл не от хорошей жизни) Был неопытный, совершил много ошибок, но добила меня пандемия. Так что согласен, но просто я наверное опустил ряд деталей про которые можно рассказать. Закрывал я студию, не как успешный кейс с чемоданом денег, а с минусом в несколько миллионов рублей. И этот минус я разгребал ещё пару лет.
Тут может показаться, что это история успеха, так как я в целом всегда на позитиве. Но на самом деле — это просто история на данный момент, и всё ещё впереди :) И деятельность моя текущая не всем подойдёт, она тоже имеет свои скажем так особенности. Но карьерные советы рабочие, так как просто я понимаю с разных точек зрения как сейчас устроен рынок найма.
У меня ща конечно всё норм, есть свой продукт небольшой и куча всяких дел. Но так как я уже разорялся, я знаю что и сейчас хожу "по ох***но тонкому льду" и что всегда нужно держать руку на пульсе. Но в любом случае спасибо, всегда интересно послушать мнение со стороны :)
Да мне кармы не жалко) Главное, чтобы статья была полезна тем, кому будет полезна. А в остальном. Минусов бояться — на хабр не писать :)
Плюсы за другие статьи думаю сохранят её положительной :)
https://github.com/Nox7atra/UnitySimpleHttpServer
Дак этож копипаста) Порядок 65353 или 65535 не так сильно бросается в глаза :) Я просто не увидел)
В статье просто небольшая опечатка. Сейчас поправлю 65535 конечно же. Откуда? Достаточно посмотреть структуру пакета TCP. И порт там занимает 16 бит. 2^16-1 = 65535. Но всё ещё не понимаю реакцию, так как это явно опечатка
Ну я даже немного распространю. Плохое соединение на выставках - это скорее не перегружен траффик, а радиошум. Так как много железа, телефонов и другого оборудования. Можно решить 100% - дорогим оборудованием, но с обычным тут могут быть риски задержек. Причём весьма высоких. Но эту проблему можно решить только шнуром. Потому что там и персистент коннект не спасёт, так как оборудование банально пингуется долго. Поэтому обычно когда такая штука разворачивается, ставятся специфичные условия. Хотя бы приличный роутер :)
Но геймпад это один пример применения вшитого http сервера. Есть геймплеи где задержка нажатия в 1 секунду не играет вообще никакой роли. Иногда нужно администрировать Unity приложения, которые вообще не игры. И удобнее это делать с планшетов. Но при этом с точки зрения апдейта и деплоя в разы проще просто обновлять контейнер на сервере в котором и веб лежит.
Да вы правы. Это можно немного решить, если поддержать Keep-Alive, но в общем да. Тут скорее "нет смысла в контексте рассматриваемых условий". А я рассматриваю условия "хорошие". В среднем сейчас слабый сервер, как контекст, скорее редкость, а вот плохое соединение может сыграть роль