mayton2019

Смотрю ролики по программированию. Заинтересовали ролики Немчинского (хотя некоторые вещи он объясняет крайне непонятно для новичка).

Немчинский - популист и популяризатор своей собственной it-школы. Обычно в каждом видосе - реклама.

У него есть контр-образовательная позиция. Он например считает что после 1 курса универа надо сразу идти работать и наплевать на диплом вообще.

Во многих роликах Немчинский говорит, что надо использовать классы через интерфейсы.
....
У меня есть класс 1, в нем есть методы. Класс 1 используется в классе 2. Зачем интерфейс?

Не смотрел видео. Но в этом вобщем-то есть смысл для создания слабой зацепленности и InversionOfConrol.
Новичку такое объяснить нельзя. Нужны месяцы и годы чтобы понять. Желательно не на синтетических
уроках а на реальных боевых проектах где МНОГО кода. Именно обилие кода и требование проводить
сложны рефакторинги, замены движков одни на другие и цикл постоянной доработки - мотивируют к
внедрению базовых интерфейсов вместо классов.

То что ты не понял с 1 раза - это нормально. Я тоже когда изучал ооп и полиморфизм на примере Borland Pascal
тоже подумал что это туфта и я это использовать никогда не буду ибо незачем.

Можно привести пример на php и показать выгоду такого подхода?

Тут я не уверен. Вроде в PHP OOP есть с 5 версии. А есть ли там механики полиморфизма - ХЗ.
Пускай знающие прокоментируют. Но если есть - то хороший пример переключения
функционала например с Db MySQL на Postgresql без переписывания бизнес-логики.
В идеале у вас переключение должно произойти в 1 строчке кода. Если удалось - значит
метод работает.

Тут Spark не имеет никаких преимуществ перед обычным приложением. Скорее всего чтение из json не распараллелится. Такой он вредный json.

Попробуй просто выкачать json через hdfs tools и толкнуть его в кликхаус обычным java или python ротложннием. И jdbc лучше не использовать. Если у кликхауса есть другой API то бери его. Будет быстрее чем jdbc.

Делать его бином тоже как-то не хочется

Не совсем понятно почему не хочется. Экономишь память? Или время иниализации бина?

У тебя проблема вовсе не в Spring. Здесь если убрать Spring за скобки - то ты также будешь ломать
голову над тем как разложить твои данные по методам.

Попробуй реши эту задачу вообще без Spring. Будет простое ООП-решение. Вот затащи его потом
в Spring и вопрос сам собой решится.

Рекурсия нужна при обработке иерархических данных. Например - обойти файлы и каталоги
в файловой системе и выполнить какое-то действие. Или действие с условием. Например если
в текущем фолдере есть фолдер .git - то выполнить какой-то git script.

Рекурсия может понадобиться при работе с документами XML/JSon (шаблон composer). И хотя
в некоторых API рекурсия может быть частично скрыта за языками XPath/JSonPath тем не меннее
ее рекурсивная природа остается налицо. Кроме того если вам достался узкий API типа DomDocument
без поисковых диалектов - то обойти его можно на любом ЯП с рекурсивной функцией.

Рекурсия нужна при парсинге сайтов. Это вобщем просто более расширенная трактовка работы с файловой
системой. Если Url-s это как-бы файлы в web пространстве и они имеют ссылки друг на друга - то вы
можете рекурсией это все обходить.

Рекурсия почти всегда нужна при работе с графами. Берите любой алгорим на теорию графов и я готов
спорить что 99% он будет содержать рекурсию.

Все настольные игры (шахматы-шашки) в основе своего алгоритма альфа-бета поиска с отсечениями и
BWF базируются на рекурсии.

Tar и gzip это очень старые утилиты. Им по 30-40 лет. И создавались они в те времена когда симметричное шифрование еще не было так развито.

Но архивчик можно после упаковки зашифровать другими утилитами например openssl.

openssl enc -in file.txt -out encypted_file.txt -e -aes256

Я так делал когда шифровал бекапы oracle dbms.

Если переписать чуть лучше скрипт - то можно объединить операции tar->gzip->openssl в один пайплайн
без воздания промежуточных файлов.

Попробуй замени any на bytes.
map<string,bytes> property = 1;

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

SELECT  name, number_plate, violation
FROM fine
GROUP BY name, number_plate, violation
HAVING count(*) > 1

если используется GROUP BY то в выражении SELECT должна стоять функция агрегации (count в данном случае)

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

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

И на качество самого аккумулятора влияет качество лития. Тут надо смотреть что за завод его делал. Из чего. Но тут я не спец. Нужны химики.

Здесь правда подходит любой алгоритм генерации лабиринтов с одним условием. Беря во внимание полярные координаты, ширина проходов в центральной части лабиринта должна быть примерно соизмерима с шириной проходов у края круга. Этого нельзя добиться просто заменив один прямоугольник на боковую поверхность цилиндра (бублика). Нужна коррекция. Корреция с учотом дистанции к центру этого бублика.

Это мне кажется интересная часть задачи которую можно обсудить. Остальное - уже решено.

Если ты говоришь о нормализации - то никак. 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. Через какой-то документ имеющий научный смысл.

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