Vitsliputsli

Если уж говорить об едином методе, то скорее так:

function getSetAge(?int $age=null): int
{
    if (!is_null($age)) {
        $this->age = $age;
    }
    return $this->age;
}}

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

Можно, но с умом. При невысокой нагрузке, база данных скорее всего простит вам это. При высокой относитесь к json как к обычной строке, т.е. без всяких индексов и поисков по параметру внутри json, максимум когда выборка уже сделана, можно попросить СУБД выбрать нужный атрибут. Как бы PostgreSQL не агитировал за json, поиск по его внутренностям всегда будет хуже по производительности.

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

$fileName = '1.csv';
$lineLength = 1024;
$linesCount = 15;

$handle = fopen($fileName, "r");
$fileSize = filesize($fileName);
$data = [];
if ($fileSize !== 0) {
   for ($num = 1; $num <= $linesCount; $num++) {
       $rand = rand(0, $fileSize);
       fseek($handle, $rand);
       $firstPointer = null;
       do {
           fgets($handle); // trash
           $pointer = ftell($handle);
           if ($pointer === $fileSize) {
               fseek($handle, 0);
               $pointer = 0;
           }
           if ($pointer === $firstPointer) { // loop detect
               continue 2;
           }
           $firstPointer = $firstPointer ?? $pointer;
       } while (array_key_exists($pointer, $data));
       $data[$pointer] = fgets($handle);
   }
}
ksort($data); // sort by order in file
var_dump($data);

Я здесь не делал защиты от ошибок файловых функций, в этом случае результат может быть неожиданным. Для защиты нужно обернуть все файловые функции и при ошибке выкидывать Exception, а не эти тупые php-шные false. Ну и помнить про ограничение длины строки в $lineLength.

выполнять сырые sql

Любая СУБД предоставляет широкое управление доступом, поэтому вполне можно этим вопользоваться. Если учебные таблицы нужно только читать, то можно держать их в одном месте, ограничив доступ только на чтение. Т.к. менять данные они будут только свои, то лочить друг друга не смогут. Также надо посмотреть лимиты для кол-во данных, которые пользователи могут залить в БД. Лимитировать кол-во создаваемых БД.
Несмотря на все, разумеется, лучше весь этот зоопарк держать на отдельной СУБД.
Можно, конечно, сделать это и через контейнеры. Но такая изоляция здесь не особо нужна, а накладные расходы будут очень велики, если у вас не 2 пользователя.

Так как соединение долго не использовалось, MySQL тупо его оборвал.
Используйте для бота systemd unit с перезапуском при ошибке, ошибки бывают разные, пускай перезапускается автоматически. Хоть это и решит проблему, лучше все-таки разрывать соединение, если оно долго не используется. Или, на худой конец восстанавливать его при обрыве.

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

По требованиям описанным в задаче:


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

Ситуация мягко говоря странная, поэтому странные вопросы: проверьте, что у вас действительно заключен договор - есть ли у вас договор подписанный простой или электронной подписью? Понимаю, что там чтото на Госуслугах пишется, но все же. Договор трудовой или ГПХ? В порядке бреда: не может ли быть так, что на вас оформлена новая карта и зарплата идет туда. И, по новым законам, есть еще и волонтерство, с договором по котором работник несет такие же обязанности, что и по трудовому, но ему можно еще и не платить.
В принципе, за нарушение дисциплины труда, вас могут уволить, если захотят, но видно не хотят. Но при этом, понятное дело, зарплату платить обязаны. За невовремя выплаченную зарплату компания попадает на штрафы. Также запрещается работа из-за пределов территории России. И очень большие штрафы, если работник числится в компании, но не является налоговым резидентом России.
Это очень странная контора будет, если ей и на штрафы тоже плевать.

$s="fja fjd jkfd
fjdk fjdktest: fjkd jk
1 1 2"
echo "${s%test:*}"
echo "${s#*test:}"

Про форматирование, конечно, верно пишут, но если про него забыть (очень оно не стандартное, но я бы не сказал, что прям какое-то нечитабельное), то просто беглым взглядом:
1) Нет ООП (а это сейчас обязательный стандарт), попытка выдать за ООП набор статических классов делает только хуже, пишите уж лучше честно процедурно.
2) SQL-инъекции! Да и весь блок работы с СУБД чтото ужасное. Куча бесполезного, реконнекты при каждом запросе...
3) ТТУК, если конечно вообще подразумевался mvc, и контроллер это index.php.
4) Вместо автолоадера просто подключение всего и вся. Хотя по факту в php сейчас стандарт - composer.

Обычно в /etc/default/grub написано на чистом английском:
If you change this file, run 'update-grub' afterwards to update /boot/grub/grub.cfg.

Вероятно так и следует сделать.

Зачем?
Так как вы хотите не делается с точки зрения безопасности.А автоматизация производится через настройки sudoers.

Вы выводите поле is_poisk, он это и показывает, хотите считать кол-во строк - используйте функцию для подсчета строк.

Если весь массив умещается в память это уже хорошо. Как оптимизировать:
1) Создайте массивы не ассоциативные, а с обычными числовыми ключами. Лучше так и хранить, будет отдельно массив url и массив cnt, связь по числовому ключу.
2) Храните отсортированный массив, и используйте по нему, например, бинарный поиск.
3) Дополнительно можно использовать массив фиксированной длины из SPL, а не стандартный на хеш-таблицах, на таких объемах от него будет толк.

Подскажите на каком языке лучше всего Websocket? чтобы он был менее затратны в производительности и более всего понятен для изучения? :)

Go.

прочитал, что могут быть разные утечки памяти, если на php делать

Не будет, если сами их не создадите.