Saboteur

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

Или второй вариант - приходит к тебе джун с таким же вопросом,
А ты ему отвечаешь
"Тут юзай синглтон, тут фабричный метод, тут подойдешь потом посмотрим что выйдет, тут пока сделай декоратор с заглушкой."
И можно идти начинать работать.

Конкретная реализация различных паттернов - это огромный опыт.
Но в первую очередь это просто обычная терминология.
Да, конечно паттерн как термин и понятие отличается от термина типа "интерпретатор и компилятор" тем, что сложно его объяснить в двух словах - надо потратить время на изучение, а желательно еще и попытаться написать парочку объектов для набивки руки.
Но собственно это от джуниора и требуется - владеть терминологией на достаточном уровне, чтобы экономить много времени.

Файлы вроде как у вас везде заданы с полным путем, но я подозреваю, что при запуске крона PATH не содержит всего чего нужно
В идеале было бы просто добавить в кроне скрипт с перенаправлением вывода ошибок и посмотреть логи, типа так

Попробуйте либо прописать полный путь к iconv и grep либо добавить в кроне перенаправление вывода в лог и посмотреть на что ругается скрипт

1 * * * * /bin/sh /home/user/script.sh>>$HOME/script.log 2>&1

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

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

cat /proc/filesystems
и смотри, есть ли там ntfs
если нет, то никак, надо устанавливать подержку, или ждать пока ntfs появится в ядре вашего дистрибутива (еще нет ни одного дистрибутива, хотя планируется)

Так спросите у тех, кто задал задание, ибо неизвестно что они себе придумали.

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

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

Нелюбопытные программисты остаются на уровне стабильный джун - средний мид.

Нет у вас доступа заходить на промежуточные хосты и с них что-то куда-то тестировать.

Представьте, что вы впервые в жизни видите компьютер с мышкой.
Как скопировать файл? Как догадаться что оказывается можно зайти в папку (что это?), как догадаться что для этого нужно навести курсор и нажать именно левую кнопку мышки да еще и два раза, да еще и быстро. Да еще и несколько раз, пока не зайдешь в нужную папку.
Как догадаться, что нужный файлик нужно перетянуть мышкой (да еще и догадаться что именно левой кнопкой), да еще и куда тянуть? Как догадаться, что можно открыть на рабочем столе сразу ДВЕ папки?
А еще ручки кривые, к мышке непривычные, в мелкие иконки попасть выходит не сразу, при нажатии кнопки мышка сама двигается, пока поймешь как скопировать файл, за это время успеешь пару файлов или папок куда-то переместить и даже нельзя посмотреть логи куда и что переместил.

Как вы видите, это простое действие на самом деле очень сложное, просто вы его изучили.

Также и с командной строкой - это не устаревший, а актуальный способ взаимодействия с компьютером, который активно используется при работе с удаленными серверами.
Советы простые - берешь и осваиваешь работу команд cd, ls, cp, mv, cat
пару часов должно быть достаточно, если потренироваться на какой-то виртуалке.

Ну все руками делается.
Делаете каталог для файлов миграции и в нем какой-то главный типа control.sh
в control.sh инклюдите актуальные файлы миграции
Для дедупликации проще всего в базе сделать таблицу, в которую при миграции добавляется "дата, имя скрипта миграции, статус (completed/failed), и при выполнении скрипта миграции соответствнено он проверяет по базе выполнялся уже или нет, чтобы не запускаться вторично. Может быть какие-то скрипты наоборот нужно прогонять каждый раз, тогда можно в таблицу добавить колонку для такого флага.

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

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

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

1. Можете привести нормальный пример структуры таблиц, тогда можно будет подумать.
2. Посмотрите ЛЮБУЮ CMS, как там сделано

В моём понимании 4 таблицы, где много одинаковых полей - это не очень нормально.

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

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

Это паранойя.

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

Но в итоге оказывается, что данный IP не назначался определенному клиенту провайдера. Под данным внешним IP-адресом в такое-то время сидело около 100 клиентов за NAT провайдера. Как будут вычислять из этих 100 человек, кто же именно сидел под данной фейковой страницей ВК?

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

Да делай как хочешь. Никто тебе не мешает удалить впоследствии проект или репозиторий.
Можешь объединить, можешь распределить. Гитхаб - это твой личный сервис, а не портфолио. Захочешь сделать портфолио - можно будет либо еще один гитхаб сделать, или этот потом почистить. Не парься, это не высший вопрос.

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

Предположим, у тебя выполняется компиляция продукта. тысячи маленьких файликов считаны, обработаны. Для каждого создан небольшой obj файлик (от десятков байт до пары мегабайт) и записан. Затем линкер по ним всем пробегает и собирает уже в основной исполняемый файл.
То есть выполняется несколько тысяч операций прочитаь/записать пару килобайт.

Быстрый кеш поможет тебе быстро взять сотню операций в себя, а затем подумать и записать в основную память одной длинной операцией.
Таким образом на основную память все будет записано словно это была линейная операция.

Динамический и статический - это просто что туда класть. Статический нарезан под готовые кусочки, динамический позволяет сохранить и килобайт и 100 килобайт и гигабайт отдельно нарезанным кусочком под каждую операцию, но будет чуть медленнее.
P.S. В конечном счете, все будет упираться скорее всего в размер кластера дисковой системы.
Почитай детали, если надо https://www.atpinc.com/blog/what-is-SLC-cache-diff...

Но. На линейное копирование крупных файлов, кеш обычно практически не влияет