mayton2019

Если ты говоришь о нормализации - то никак. JSON не предполагает никаких ссылочных связей внутрь документа. Считай что JSON - это денормализованная копия БД. Как с этим жить - большой вопрос. И его надо обсуждать поняв что тебе на самом деле нужно. Потому что конвертация EAV в JSON это какая-то странная очень узкая задача. Может тебе на самом деле это и не надо.

Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

Зачем такой ужас. Делай только те репозитарии которые реально задействованы в бизнес-задачах.
Из личного опыта могу сказать что если приложение спроектировано по умному - то ему не нужно
выделять каждую таблицу в Entity.

Мне кажется что внедрение WebFlux идет от "реактивного манифеста". Вообще классические сервлетные серваки которые раньше поддерживались Tomcat/Jetty сегодня могут быть прозрачно подменены на netty, на уровне конфигураций бута, что как-бы приближает нас к асинхронщине. И современному бизнес-разработчику практически будет безразлично, написан ли его контроллер на блокирующем IO или на каком-то другом. По сути речь идет о диспетчеризации ресурсов. Где создавать поток. А где и хватит единого потока диспетчера на всех.

По поводу WebFlux, я видел один проект по обработке web-messages и это было удобно. Но только если мы на уровне алгоритма гарантируем что хендлер месседжа не будет занимать много времени.

Да нет такой метрики. В bigdata запросы могут по несколько часов или несколько суток работать.

Во всем что работает с вебом - надо выйти на быструю отрисовку landing page. TTFB. Не более 3х секунд желательно.

На олимпиадах обычно подбирают такие задачи где вам не понадобятся ни http клиент ни json парсер.

Вам понадобится знание алгоритмов и способность быстро синтезировать новые. Для этого уровня разработки будет достаточно самых базовых сущностей языка.

Его никто не будет смотреть скорее всего.
Просто формат такого общения как кидание ссылками предполагает что вы совсем не цените собеседника.
Мне вот вообще не интересно смотреть никакие гитхабы без наличия автора рядом. Чтобы он дал
поясняющие комметарии по каждой строчке кода. В противном случае я подумаю ... нет я побоюсь
такое подумать что меня просто обманывают и подсовывают чуждой код.

Код как и курсовой требует защиты. А также вступительной речи на тему зачем это вообще нужно и какова
мотивация.

Список символов - это строка в Haskell.

Просто так договорились. Это как договорились в С++ что строка ASCIZ это вектор символов который всегда завершается нулевы байтом. Этот факт никого не смущает? Все нормально сглотнули и пошли кодить. Верно?

А по поводу прочих синтаксических конфет - все в правовом поле. Все логично. Haskell - вообще один из самых строгих и логичных языков. В нем даже change-requests происходят не просто как в других языках. Не просто хотелки. Там - любое изменение - это через paper. Через какой-то документ имеющий научный смысл.

У тебя - рекурсия. Попробуй расчитать какой она глубины.

Сколько запросов в секунду - наперед никто не знает.

Для оценки обычно берут аналогичную систему и пытаются как-то экстраполировать.

В любом случае, если вы создаёте что-то новое - от вас требуется POC и бенчмарк. Без этого вы будете неубедительны.

Несколько лет назад один господин, известный в кругу дизайнеров хвастался тем что создал ИИ который рисует логотипы. Я смотрел портфолио этих работ. Не впечатлило. Скорее всего имел место генератор случайных цветов и шрифтов и оформлений для букв логотипа.

Так вот. Для генерации цветных штанов - никакие сети не нужны. Более того. Если вычеркнуть слово нейросеть из технического задания - то тогда и цена разработки будет ниже. А эффект - тот-же самый. Набор штанов. Но без пафосных слов.

Вобщем думайте что вам на самом деле надо. Сделать штаны. Или распилить бюджет на разработку.

Проще всего вести лог транзакций монет по всем пользователям. В сущности User можно оставить только баланс.
А если кто-то захочет посмотреть какие есть монеты - то можно проверить лог по пользователю и собрать отчет.

Вобщем надо исходить из предположения что такой запрос будет не очень частым.

C++ не самый - лучший старт для начинающего. Можно выгореть на самом начале при работе со строками и адресной арифметикой. Тем паче, что C#/Delphi например, предлагая аналогичные возможности языка с типизацией, страхуют от такого выгорания.

В этой операции мало смысла. Расскажи что будешь дальше делать - и я подскажу как. Возможно тебе нужен Pandas.

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

Да. С точки зрения современных технологий управления исходным кодом - это нормально. Это выглядит бюрократично - но это защита, когда что-то пошло не так. Всегда можно без участия автора взять и откатить назад точечно именно то изменение которое привело к ошибкам за 1 день до релиза.

И сложно себе представить что нужно откатить если ты ушел в отпуск и в 1 мердж реквест положил штук 5 своих задач.

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

Квотировал не только с вопроса но и с ответов автора.

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

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

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

Надо посмотреть покрыты ли основные бизнес-кейсы авто-тестами. Самый простой пример.
Берете и ломаете свой исходник в одном месте. И тесты должны это заметить. Если не замечают
- это проблема.

Владею стеком HTML/CSS/JS, Python+django/fastApi, java(для математики всякой)

Также хоббийно занимаюсь микроэлектроникой(avr/nrf/stm)

Выглядит как активность эникейщика. Первая предметная область, связанная с фронт-вебом - сегодня очень сложна. И чтобы по настоящему расти - надо отдаваться ей на 100%. Иначе эффекта не будет.

Я не хочу говорить что ты распыляешся, но резюме выглядит как, как будто ты еще находишся в творческом поиске и давать тебе какие-то проекты еще рано. Может тебе имеет смысл еще погулять пару лет и после этого просто "зачистить" свою анкету от посторонних мешающих хеш-тегов.

Я сам так сделал и не жалею. Всякие Photoshop/3DMax/радио-и-связь/игра на трубе/вязание крючком - заказчика не интересуют а вобщем даже и раздражают. Под позицию нужен профессионал а не разно-рабочий.

UPD: