mayton2019

Я много писал веб на PHP (с фреймворками), но давно хотел перейти на Java, Spring и т.д.

Поздравляю. Ты теперь откроешь для себя целую вселенную и поймешь что Java - очень разная.
Например стоило-бы отличать Java Android и все остальное.

По поводу процесса компилляции. Почитай про технологии JSP-страничек. Она очень похожа
на PHP по своей задумке. И там реакция на изменения кода чуть быстрее чем в Servlet-приложении
хотя JSP идеологически является макросом над сервлетом.

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

Оказалось, что приложению надо 3-4 минуты, только чтобы стартануть на машине разработчика.

Это нормально. Мне попадались очень тяжелые монолиты которые на мощных машинах стартовали
по 30-40 минут. Да и такое бывает. Это тяжелая приставка *enterprise. И конечно это идеологически
отличает Java от PHP. Для корпоративных приложений в принипе неважно сколько они стартуют.
Главное когад они уже стартовали и 30 минут прогревали кеши из БД например то биржа будет
работать быстрее в runtime. Вот. А подготовку к работе можно делать и 30 минут - это тоже ОК.
Главное что клиент это не замечает в силу закрытого опер-дня и Blue-Green deployment.
Тоже почитай про это кстати. Полезно.

Из-за долгих перезапусков (тем более на новом для меня проекте) разработка шла долго и мучительно.

Могу посоветовать сфокусироваться на модульных тестах. То как ты разрабатывал раньше, сверяя
каждый символ с браузером - может быть не эффективным. По сути если ты написал бизнес-логику
и дизайн для нее готов и твоя задача просто проверить что функии получили на вход инпуты
и выдали верные аутпуты - то значит задача на 99% решена и можно релизить.

С точки зрения например корпоративного процесса разработки - любая фича разрабатывается 1 день. Это я меряю
по себе. Беря во внимание чтение ТЗ. Разработку. Цикл тестирование. Деплойменты. Аксептенсы и прочее.
И если тебя просят покрасить кнопочку с красного цвета на синий - ты спокойно сообщай что
это занимает 1 день в конвейере процессов. И это нормально. Это корпоративная бюрократия.
И Java - бюрократична. И ты главное не стрессуй а просто используй эту бюрократию в свою
пользу. Пей кофе. Читай книги пока идет deploy pipeline.

Идеальным считается Шифр Вернама. В принципе это идея Книги Кодов или одноразового блокнота.
При его использовании Алиса и Боб могли-бы спокойно переписываться и быть уверенными что никто
их не читает. Но здесь возникает вопросы.

Как Алиса и Боб ей обменяются?. Совершенно очевидно что
классические цифровые каналы здесь не подходят. Нужна личная встреча. Иначе слабым местом
в протоколе становится не Вернам а тот способ которым произошел обмен.

Как ее сгенерируют? Нельзя использовать классические ГПСЧ иначе они станут еще
одним слабым местом. Очевидно что книга кодов должна создаваться очень оригинальным
и неповторимым методом который не дает злоумышленнику (Кларку например) никаких
гипотез. Аналоговый шум радиоэфира. Рулетка. Игральные кости. Карты. Короче
любые источники энтропии которые никак не связаны с цифровым миром где Кларк
может строть гипотезы. Кроме того книга кодов (КК) должна быть достаточно
длинной (я-бы рекомендовал терабайты) чтобы Алиса и Боб хотя-бы на пару
лет могли не встречаться повторно для обмена новой книгой.

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

Можно попробовать вот эту фичу (Redis Queue)
https://redis.io/glossary/redis-queue/

Не должно быть "слишком долго". Как раз как хочет автор. :)

Автор ищет функцию следующего вида.

def (pointA : point, pointB : point, figures : list) -> list

На вход приходит например точка А. Это где мы стоим. И точка Б - это выход из лабиринта.
Это впрочем мое видение задачи. Можно и изменить. И список фигур (полигоны) третьим
аргументом. И результат - список координат - траектория движения. Как выбежать из лабиринта.
Если решения не существует (например мы огородили точку А кольцом камней) то функция
должна вернуть например None.

В классическом варианте движение из точки А в точку Б в лабиринте реализуется на клеточном
поле алгоримом Волны или Волновым алгоримом.
https://habr.com/en/search/?target_type=posts&orde...]

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

По поводу нейросетей. Тема модная и не сходит с топ обсуждений.

Я предлагаю вместо нейросетевого решения обсудить кейсы когда решения не существует
а НС об этом не знает или не умеет такое детектировать. Если мы будем подмахивать нейросети
и подсовывать ей заведомо легкие решение (нет сплошной стены из фигур вокруг точки А например).
то это решение будет туфтой. И также туфтой будет нейросеть сколь бы умно она не выглядела.

Почему я решил пойти от негативного кейса? Мне кажется это - вопрос интересный и дискуссионный.
Это как доказательство теоремы. В случае алгоритма волны - это возможно. Если волна заполнила
все пространство вокруг А и не достигла Б - значит решения нет.

Кроме нейросетей есть еще комбинирование рандомных решений с улучшениями (генетические
алгоритмы). С точки зрения лабиртнта это выглядит как построение большого количества
случайных путей из точки А в точку Б с отбором тех путей которые
- которые короче другие
- которые не пересекают края фигур

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

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

Основной use-case при работе с любыми данными это "запрос".

Ты должен задать себе вопрос как я буду эти данные искать? По каким атрибутам?
Например базы данных семейства key-value почти всегда всем подходят и всем нравятся
за высокую скорость и дешевизну. Но это - только при условии что вы делаете поиск по ключевым атрибутам.
Но вы не сможете к ним сделать агрегации (group by).

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

Из личного опыта. Часто выбирают какую-то БД из того что человек (команда) уже раньше
с ней поработали и уже имеет опыт. И такое реально было и с Ораклом и с MS-SQL. Люди их
выбирали не потому что они хороши а чаще всего потому что "так привыкли". И десяток
лицензий были уже давно куплены. Почему-бы не использовать. Заказчик оплатил.
Так жить проще. Так и живут. И так строят архитектуры.

Капец много текста написал.

Если кратко - то найди себе ментора. Это позволит тебе не выгорать а двигаться
вперед.

Должен был написан план с датами что изучать. С++ - очень сложный язык
и в нем ного фичей. Даже его создатель рекомендует не брать все сразу
фичи а изучать какое-то разумное подмножество.

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

Код должен содержать тесты и иметь какие-то критерии качества и эстетики кода.

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