Станислав Родионов @ddinochrome
Fullstack-разработчик
Информация
- В рейтинге
- 398-й
- Откуда
- Москва, Москва и Московская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Fullstack Developer
Lead
JavaScript
Node.js
PostgreSQL
C++
Zig
WebGL
Game Development
Web development
Project management
UI/UX design
Спасибо за замечание, я добавил предложенный вами вариант реализации uuid v7 в список. По приведённым ниже графам исходников видно, что реализация от TheEdoRan более компактная, поэтому изначально я её и выбрал.
Если вас не затруднит, напишите, пожалуйста, аргументацию вашей позиции.
Это можно сделать в отдельной статье, где будет рассмотрен хостинг фулл-стек приложения на разных платформах. Для плагина автотесты не особенно актуальны.
Хорошо, сделаю обзор Source Craft по сравнению с GitHub и GitVerse на примере хостинга для того же самого расширения.
Насколько я знаю работа по созданию такого языка ведётся: https://metalanguage.tech/
По набору фичей для первого курса неплохой результат. Правда в реальной разработке совсем другие проблемы — миддлвара затачивается под реальные задачи использующих её приложений, и это сильно меняет процесс постановки и решения задач.
Как мне кажется, сейчас вы просто смотрите на чужие движки и делаете себе такое же. Но в коммерческой разработке такой подход будет только мешать. Я думаю, что движок эффективнее делать под конкретную игру — тогда вы получите более релевантный опыт. Так-то на рынке много программистов, умеющих реализовать сферический движок в вакууме. Но обычно эти решения не позволяют получить прибыли при использовании на реальных проектах, призванных приносить деньги. А вот программистов, оптимизирующих движки под нужды целевого проекта, — мало, они более эффективны и высоко ценятся работодателями.
В целом графика в демке смотрится интересно. Только транспорт выглядит каким-то игрушечным пластмассовым. Особенно непрозрачные стекла автомобилей усиливают такое ощущение.
Blitz — это нишевый движок, поэтому подойдёт только для небольшого спектра проектов. Среди движков общего назначения с развитой экосистемой и коммьюнити у нас так и останутся U и UE.
Судя по Вашей логике, нам стоит ждать новый язык программирования от Сбербанка или Газпрома) Но этого не будет. Это не их тема, они не смогут в это грамотно инвестировать.
Так-то даже новый язык программирования или даже ОС можно сделать силами небольшой команды. Не то что нишевый движок. Тут вопрос в первую очередь не в финансировании или численности команды, а в её квалификации и мотивации.
Что касается самоокупаемости… А почему Вы решили, что для данного стартапа это цель? Скажу по секрету, что игры — это вообще одна из худших сфер для самоокупаемости. По крайней мере из тех, в которых я работал.
Если вопрос только в маркетинговой целесообразности шутера на мобилах, то PUBG Mobile — это ответ. К управлению привыкаешь, неудобства компенсируются другими факторами. Например, можно поиграть по сети с друзьями, у которых из девайсов ничего кроме телефона отродясь не было.
U/UE в умелых руках позволяют сделать достаточно качественный с технологической точки зрения продукт. И я думаю, что команда Blitz смогла бы это сделать при желании. Тут вопрос в том, что прошло более 10 лет с тех пор, как была заложена базовая архитектура U/UE и с тех пор на этом уровне мало что поменялось. Плюс в то время основной упор был на десктопы и консоли. Мобильные девайсы и веб появились как внезапный довесок) Соответственно, видя современные расклады по 3Д для шутеров на мобилах, можно замутить на уровне движка что-то более интересное с точки зрения фичей и утилизации ресурсов железа. Главное — чтобы команда по подготовке игровых ресурсов оптимально использовала все особенности движка. Иначе может и хуже U/UE получиться.
Как человек, переходивший во времена расцвета Unity с C++ на C#, я могу сказать, что после плюсов для переезда на шарп хватает 1 дня. Тут вопрос образа жизни. Это как с Oracle перейти в Excel, как пересесть с Ferrari на Hyundai. То есть с коммерческой точки зрения это выгоднее, но не круто, совсем не круто… Стоит ли уходить со стабильной работы, чтобы создавать собственный проект на компромиссах и технологиях аля-1С?
Вобщем, я думаю тут будет рассказ не про продукт, а про образ жизни. И это интересно)
Raspberry Pi 4 купить из России на официальном сайте нельзя — пишут нет реселлера в вашей стране. Куда ещё податься страждущим?
К сожалению, это всё проприетарщина, поэтому публичных материалов нет.
Для успеха нужно создать то, на что легко перейти, и что даст такие большие выгоды, которые легко мотивируют на этот переход. Я думаю, тут в первую очередь стоит вопрос не технологий, а идеи и видения.
Ну и плюс авторы QP ОС написали, что первое ядро скомпилили в 2005 году. Поэтому если даже это делали 2 человека, они скоро перевалят за 30 человеколет.
Я у себя этот вопрос решаю просто. У каждого сотрудника есть определённый ежемесячный доход, который ему нужен для жизни. Это может быть фиксированная сумма, а может быть что-то плавающее. Но в любом случае оно плавает в определённых пределах. Соответственно, можно получить стоимость каждого часа содержания сотрудника — не важно, работает он, спит или играет в покемонов. Например, при ставке 100 тр/месяц стоимость каждого часа будет 100 000 р /(30 * 24 часа) ≈ 140 р/час. Таймер для сотрудников включен всегда — и ночью, и на выходных, и на праздниках.
Я могу за любой промежуток времени посмотреть что сотрудник сделал полезного и сколько компания на это потратила денег. Если виден профит для компании, то мне не важно сколько из этих часов было отработано, а сколько было потрачено на сон и покемонов. А если профита не видно, то надо или что-то менять, или прощаться друг с другом.
Непосредственный подсчёт отработанного времени хорош только с точки зрения психологии — по нему легче отчитываться перед заказчиком. Так исторически сложилось, что это — привычная для всех схема. Но насколько она эффективна для PMа в качестве инструмента контроля? Лично мне она только мешает, потому что, как уже многие заметили в других комментариях, трудно замерить какое время было рабочим, а какое — нет. Ещё более трудно понять где границы задачи и сколько времени в итоге займёт её решение. И все эти трудности приходится решать PMу в ущерб реальным полезным для проекта задачам.