Saboteur

Я одно время пробовал синхроинизроваться через git при смене машины (reset --hard при каждом пересаживании)

Честно говоря, IMHO вам следует научиться работать с git, потому что reset --hard при каждом пересаживании - это вы прямо вообще неправильно пользуетесь инструментом.
А так git это именно то, что надо для синхронизации.

паттерн executor что-то типа:

array { id, name, function}
[ 0, 'объект1', 'function1' ],
[ 1, 'объект2', 'function2'],
[3, 'объект3', 'function1;function3']

while ID in array(id) {
eval array(function)
}

или switch/case

Я думаю в профайле пользователя задается определенная локаль, которая позволяет работать нормально с кодировкой, а через crontab она не задается.
Посмотрите еще раз ваш .profile, .bashrc и настройте такое же для крона.

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

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

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

Файлы вроде как у вас везде заданы с полным путем, но я подозреваю, что при запуске крона 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 таблицы, где много одинаковых полей - это не очень нормально.

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