Виктор П.

есть готовые
https://blog.tensorflow.org/2018/05/real-time-huma...



так и гуглить
tensorflow js computer vision

$('[data-submit]').on('submit', function (e) {
        e.preventDefault();
        // ... тут обрабатываем и валидируем
        this.form.submit();
    })

1) правда ли изучаешь один раз и применяешь везде?

да.
У нас не принято собирать разнообразные велосипеды из набора либ. Разве что стейты vs сервисы :)
Меня всегда это вымораживало в реакте, чтобы реализовать привычные вещи приходится тащить черти что и еще выбирать самому. А чтобы выбирать нужно уже знать варианты.

2) как обстоят дела в крупных проектах?

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

Архитектура приложений будет больше зависеть не от Ангуляра, а от знакомства разрабов с принципами построения архитектур, которые в целом несложны.
Сам Ангуляр ничего не навязывает, Nuxt в этом плане даже более структурирован. Однако и так все само получается примерно схоже. Отчасти поэтому nuxt/next для ангуляра не существует.
Еще популярен Nx, который помогает собрать монорепу из angular+nestjs например.

стоит ли?

Определенно стоит ознакомиться. Некоторые практики, без которых Ангуляр сложно представить, можно использовать и в react. Например di, если еще не используете.

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

Идея сама по себе - ничего. Важно уметь реализовать ее, видеть всю картину в целом. Гугл не был первым. До него было много крупных поисковиков, больших корпораций. Кто сейчас в состоянии вспомнить их имена? Хоть 2-3.

Себе для своих личных целей я сделал за 2 дня.
На заказ сделаю за пару сотен тысяч рублей.

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

Прошу прощения, что не ответил сразу, довольно редко теперь тут бываю. Надеюсь вопрос ещё актуален, всё таки найти 35М – дело непростое. Теперь по существу вопроса. Буду исходить исключительно из того, что вы рассказали.

Прелюдия:
1. У вас есть, можно считать, готовый продукт – это очень хорошо, потому как некоторые ищут похожую сумму на этапе дизайна прототипа (практически на уровне идеи). Что ошибочно.
2. Тем не менее, продукт, который не смог принести денежного потока (речь не о прибыли), хотя бы минимального, будет не интересен инвестору -> следовательно, его нужно создать. И желательно с минимальным лукавством, о котором советовали выше ( пусть и в немного ином направлении). Я имею в виду первыми клиентами вам придётся заняться самостоятельно, чтобы показать что продукт реально имеет рынок.
3. Не совсем ясно для чего вам такая сумма. Она эквивалентна инвестициям в полную разработку продукта, по нынешним меркам. Ну да ладно, речь не об этом. Уверен, у вас всё обосновано.

Рекомендации:
1. Если вы попали на распутье, где для одних проект маловат, а для других великоват, возможным решением будет разделение суммы требуемых инвестиций на части и привлекать инвесторов для каждого этапа. Это обычная практика в венчуре: на 10 лет компании надо 500М, например, но она "размазывает" эти деньги на 4 этапа (раунда) и привлекает инвесторов под каждый из них.
2. Либо увеличьте стоимость проекта, чтобы подпадать под требования VC. И вот для этого компания должна приносить стабильный доход, прибыль может быть отрицательной, а вот выручка стабильной.
3. Повторюсь. Надеюсь у вас есть нормальная фин.модель, которая обосновывает такую сумму инвестиций. Так как она будет способствовать понимаю доли / или %, который потребует инвестор или который можно использовать в переговорах.
Мне часто задают вопрос, сколько надо давать инвестору: мой ответ – пропорционально его вкладу в будущую доходность компании. Отсюда же и проценты к возврату. И здесь эфемерная таблица "на коленке" мало полезна и впоследствии возникают разного рода конфликты и недопонимания.

Кейс:
1. Недавно меня привлекали в один проект по разработке приложения для автосервисов. Мы провели глубокий анализ рынка и сформировали детальную фин.модель, которая сполна объясняла откуда берутся деньги, сколько клиентов мы ожидаем к себе привлечь и сколько стоит всё: от разработки до продажи. Там тоже нужна была похожая сумма, которую мы разделили на 3 части согласно этапам проекта, получилось довольно приемлемо для ангела.
2. Другой проект, уже из сферы строительства, искал 15М под реальные активы. Построенный дом в Якутии и все активы компании шли бы в залог инвестиций. Желающих вложиться было много, но все они требовали гарантий от разных фондов, стоимость которых варьировала от 200 до 500 тыс ₽. У ребят таких свободных денег не было. Помимо гарантий был ряд требований с передачей ряда функций на аутсорсинг в топовые компании, стоимость которых была высока. От идеи инвестирования в итоге отказались и решили заходить через гос субсидии. Работа пока идёт.

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

Будут вопросы, пишите. Успехов!

UPD: И да, искать инвесторов для вашей игры нужно там же, где и все:
1. Различные сообщества и сайты агрегаторы – спарк, бизнес-платформа и прочие.
2. "Мучать" фонды, но только те, что работают с игровой тематикой.
3. Принять участие в какой-то выставке игр, насколько я знаю они каждый год проходят в МСК, а то и по несколько раз. Уверен, те, кто инвестирует в игры ходят туда.
4. И другие места, информация о которых, в изобилии есть в интернете. Потому как главное не место, где вы ищете, а продукт, который вы предлагаете. На ловца, как говорится, и зверь бежит.

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

Приятно смотрится.

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

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

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

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

Поэтому выходит что ответственность по ревью (или полностью, или всё кроме архитектуры) нужно делегировать лидам команд.

делегируйте, лиды затем и нужны.

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

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

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

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

Текст звучит так что у вас есть кто-то слишком за все ответственный, кто контролирует код который пишут 80-100 человек. Это заведомо гиблое дело. Либо у кого-то очень большое эго, если он сам на себя это взял, либо очень слабый характер, если на него навешали. На таких масштабах вам нужны иерархия и делегирование.

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

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

Много чего поддерживается тем-же MSVisio, но если остановитесь на чем-то конкретном - можете найти и специализированную системку.