mayton2019

Сильно зависит от background. Если автор заходит в Spring с улицы - то ему придется учить все в том числе SQL, ORM, Web, MQ. Это очень плохо и это ставит под сомнения обучение Spring.

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

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

1) A OR В И В OR А;
2) A AND ВИ В AND A;
3) (A OR В) OR С И A OR С;
4) (A AND В) AND С И A AND (В AND С);

Это не надо доказывать. Это законы коммутативности и ассоциативности булевых операций AND/OR.

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

Я никогда не слышал чтоб кто-то читал чистые алгоритмы. Обычно программа более конкретная. Например алгоритмы игровой логики. Алгоритмы маш-обучения. Обобщенные алгоритмы какого-то языка (C++) etc.

Чистые алгоритмы - это Кнут, Кормен. Короче сферическая лошадь в космосе.

Расскажи какие вещи ты уже делал на Java в реальных задача.
Любое обучение или систематизацию всегда лучше привязать к живым а не искусственным задачам.
К примеру если ты писал авто-тесты и есть задача - ускорить их финал - то тут можно изучать многопоточку
принительно к авто-тестам.

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

на сайте есть различные небольшие блоки (о нас и тд). Встречаются они единожды, но должны редактироваться менеджером -> храниться в базе.

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

Но поскольку у вас стоит такое требование как хранить в базе - отсюда и возникает вопрос.
А с каким ключом туда это все ложить? Ключ должен быть осмысленным настолько чтобы эти
блоки потом найти и не потерять. И это даже не с нормализацией а скорее просто с особенностями
подобных хранилищ. Key-Value очень быстро захламляется и превращается в свалку или кладбище
документов без внятного понимания нужны они или нет.

Если url будет ключом - то это хорошо.

Можно. Я так делал.

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

В криминалистике обычно для определения размеров объекта на фото, с ним рядом кладут что-то имеющее известный размер. Коробок спичек. Линейку. Или монету. В таком случае наверное можно сопоставить размеры.

В географии в углу карты обычно рисуют маленькую линейку масштаба. По ней тоже можно что-то определить.

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

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

А зачем сделал static?

Тут надо смотреть какие цели этой лабораторной работы. Если цель - учиться С++ - то такое решение как автор написал - вполне себе прокатит. Изучаем switch-case.

Если цель - парсеры, то решением будет разработка парсера математических выражений (ПОЛИЗ до кучи).

Если цель - интеграция - то можно просто из С++ вызать любой трансируемый язык (тот-же Perl или Python) и просто в комнадной строке передать ему выражение и получить готовый ответ.

Если цель - ООП с полиморфизмом - то можно просто развить пункт №2 придав ему красивый вид. Типа Базовый класс - BinaryOp. От него наследники Mul/Sum/Div/Minus.

Короче все эти решения будут правильными. Они все решают задачу но по разному.

В разной тык-скыть прадигме.

Да вы правы. Здесь liquibase вполне себе подходит. Можно брать более модный flyway. Но будьте внимательны. Оба этих продукта имеют бесплатную и платную функциональности. Очень часто начинающие прокалываются на чтении документации и думают что фича есть. А на самом деле она - платная.

Но для простого юзкейса (без откатов) возможностей бесплатной части вполне хватит.

Не всегда нужно кидаться в разработки потоков. Иногда есть подходы которые обеспечивают компромисс.
Например у тебя 100 000 ссылок. И ты хочешь запустить это в 16 независимых задач (процессов или потоков неважно). Предположим что у тебя уже есть процесс python который решает эту задачу в 1 поток. Далее если мы разделишь эти 100 000 сыслок на 16 частей - то ты можешь запустить 16 копий процесса передав ему параметр. Что-то вроде

$ python3 parser.py links.lst 0
$ python3 parser.py links.lst 1
....
$ python3 parser.py links.lst 15

Здесь параметр links.lst 15 означает что надо брать каждую 15 строку по модулю 16 их исходного файла.

Воспользуйся онлайн чекером здесь https://regex101.com/

Не все программисты имеют свои pet-projects. И я не стал бы обязательно настаивать на портфолио. Кроме того если кандидат работал там где есть NDA, то все понимают что он просто не имеет права публиковать собственность какой-то корпорации.

Из опыта своих собеседований я знаю что портфолио смотрят "бегло". А домашнее задание не проверяют почти никогда. Поэтому если вам будут закидывать задачки - смело посылайте дальше. Это будет зря потраченное ваше время. А вот что будет полезно. И вы можете это предложить со своей стороны.
- технический собес с лидом
- сеанс онлайн кодинга
Вот это уже ближе к делу. За час-полтора можно быстро проверить что человек за человек и как он вообще разрабатывает. И это будет более честно и прозрачно чем какие-то дурацкие пет-проекты. Тем более что в пет-проектах обычно - седьмая вода на киселе. Большая часть кода - рудимент. Не нужна. Закоммичена но не используется. Короче очень сложно понять где в пет-проекте те волшебные 20% кода которые делают ВСЁ. И именно поэтому пет-проект - никому не нужен.

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

40 метров - это зона действия хорошего Wifi. Телефонный кабель не подходит. В старых советских телефонах было 2 жилы в то время как Ethernet - 8 жил и специальное плетение для компенсации помех.

Чисто ради интереса поищи парочку DSL модемов. Тогда может получится у тебя приличная сеть на 25 Мбит.

Сам по себе список IP никому не нужен. Обычно интересует некое бизнес событие. Его точная дата и время и IP хоста который был инициатором этого события. Плюс id сеанса, cookies .e.t.c. Тоесть задача чуть более широкая.

Или автор хотел чего-то другое?

А для простых задач есть tcpdump/wireshark.

Линейная зависимость. Бери некий box, который ограничиает карточки. Его размеры - это экран минус margins.
И внутри этого бокса надо разложить карточки с одинаковым шагом. Беря во внимание что карточка тоже имеет
размер - вычитаем ширину карточки из ширины бокса. Также с высотой. Оставшееся - делим на 4 и получаем шаг.

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