Действительно ли это реалии рынка?

если человек к 20-22 годам (грубо, к окончанию универа) не стал по скиллам сеньором или хотя бы очень крепким мидлом с горящими глазами, то это просто маркер того, что человеку вообще насрать на то, чем он занимается,

Либо этот человек адекватно оценивает свои возможности. Ктонибудь видел сеньора 20 летнего, я нет, и думаю никогда не увижу.
Сеньор и мидл это опыт. Заявление, что опыт не нужен, или что опыт петпроектов релевантный опыт, это как минимум забавно. Мало того, если тебя называют сеньором в компании разрабатывающей сайты визитки, то вряд ли будешь таковым в компании с крупными проектами. Опять же, потому что нужен другой опыт.

Действительно ли это реалии рынка?

Дмитрий,

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

Можно. Но это совсем не то, что вы в начале написали

в своих хобби-проектах

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

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

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

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

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

Действительно ли это реалии рынка?

Действительно ли теперь рынок в руках умелых врунов, а не умелых инженеров?

Кто ни дня не работал, тот вряд ли "умелый инженер"

Стоит ли вообще дальше развиваться в этом направлении?

Смотря какая цель.

... я что-то делаю не так?
Каковы вообще прогнозы рынка разработки?

В России СМИ пишут, что скоро будут более востребованы токари и слесари.
В мире вряд ли чтото изменится. О том, что не нужно столько разработчиков пишут уже десятки лет в перерывах между этим пишут, что компании не могут найти разработчиков.
Вообще, найти первую работу без опыта всегда сложно в любой профессии. Порой и с опытом не всегда просто бывает. Чему тут удивляться? Тратить деньги и время на обучение стажера мало кто готов.
Сколько по времени ищите?

Как понять почему не работает событие по интервалу (MariaDB)?

Посмотрите в information_schema.events

Нормально ли дублирование строк в IN?

alexalexes,

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

для 11 значений временная таблица не будет более быстрым решением. Сам запрос наверное, но будут же еще и расходы на создание таблицы, наполнение ее данными, удаление таблицы. А т.к. это все разными запросами, то плюс сетевой лаг. Не говоря уже о том, что вместо одного понятного запроса у нас целая вереница, что когда завтра подключим СУБД как slave, свято веря, что мы только читаем, упадем на этом запросе.
В общем, я бы не стал играть с временными таблицами без прям хороших показаний для этого. А выбрать 11 значений очень слабый аргумент для этого.

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

djton1k, ну так nuc это ж и есть минипк, тогда о чем комментарий выше?

А потом придет счет за электричество плюс косарь

Почему не видно свойства?

MikMik,

Дело было действительно в разных процессах. Как только воркеры запускаются они становятся независимыми процессами и не имеют ни какого отношения к классу который их запустил, все переменные которые работают в одном воркере недоступны в другом.

Ну какие разные процессы? Здесь у нас просто 3 объекта со своими параметрами и не более того. Другое дело, как написал в ответе, нужно учитывать порядок выполнения анонимных функций.

Почему PHP считает int числа после математических операций как float?

Виктор Кожухарь, Понятно, что все в голове не удержишь, но типы это базис языка, в том числе их неявные преобразования. И, явное указание типов здесь никак не поможет. К примеру, в коде всем числам указали тип int (как у автора вопроса, потому что ему нужно целое число, а про другое он не читал), и вроде все работает, до дня Х, когда случится переполнение и следовательно конвертация в float и все ляжет. А точно нужно было так? Возможно float тоже вполне себе подошел бы? Но даже если нет, тогда нам бы следовало сделать проверку и выбросить нормальный эксепшн о превышении лимита для какой-то сущности, а не фатал: "не пихается float в int". Т.е. помощи здесь от явного указания типов 0. А вред от неизучения типов и их преобразований огромный.
Конечно польза от явных типов примитивов есть, но в отличии от языков со статической типизацией, это не более чем тупая проверка диапазона в надежде, что ошибка из него выбивается. Т.е. по-сути бизнесовая проверка, а не работа с памятью. Например, есть у нас id, целочисленный, мы обложились типом int и как бы норм, только вот id - это у нас все положительные целые числа, а int - это знаковые целые числа, обычно в диапазоне 64-бит. Диапазоны не совпадают, нужны еще проверки, но даже после них ничего не помешает пройти какому-нибудь абсолютно левому числу. И тут, гораздо эффективнее подключать типы ООП.

зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности.

Ну вот причем здесь Rust? Или выделение/освобождение памяти? Когда вы последний раз сталкивались с этой "главной проблемой современности" в php? Или вообще выделяли или освобождали память в php? Правильно, никогда, потому как у программиста там нет таких инструментов, совсем, все делается за него. И, каким боком такой сложный вопрос как выделение/освобождение памяти связан с проверками типа в php, т.е. с тупо сравнением? Это там, где типы проверяются на этапе компиляции, хотя бы тупо чтобы не прочитать как число данные, записанные как строка, там сложная работа с типами, в php где все данные маркированы типом это не нужно.

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

Как написал выше не такая логика, и вообще ничего общего. Поэтому вопрос, что за "такие баги"?

Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.

Я хрен знает что такое "мир JavaScript", я так понимаю это мир из 2х языков: js и ts? Ну тогда чему удивляться, любой адекватный язык всяк лучше js. И да, обязательное явное указание типов примитивов в ts наверное правильное решение, т.к. основная аудитория это те, кто писал на js. Даже на этом форуме кто приходит с php-шным global закидывают какашками, а времена register_global вспоминают с ужасом. Но в сторону js, с его областью видимости луковицы и прототипами никто плохого не скажет, просто у ребят альтернативный взгляд. Настолько альтернативный, что не смотря на монополию в браузерах пришлось костылями ваять ts, чтобы как то совсем не потонуть.

Почему PHP считает int числа после математических операций как float?

Помоему контроль типов в PHP вполне себе годный. Все нужное есть, а то что "явно типизировать обычную переменную не получится" - да, но оно и не нужно. Вообще, для контроля бизнесовых данных контроль примитивных типов помогает слабо, а хорошо решают проблему типы в ООП и там все что нужно есть. Поэтому для безопасности лучше использовать именно ООП. Но даже на уровне примитивов контроль есть - на уровне входа/выхода из функций, а указание типа отдельной переменной это ненужное.

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

Неявные преобразования в языке, хоть с динамической, хоть со статической типизацией, это часть движка. А вот "строгая типизация", вернее явное указание типов переменных это опциональный инструмент в php. Поэтому первое нужно знать обязательно, к том же это прекрасный инструмент. А расчет что "строгая типизация" спасет - очень опасный путь.
Изучая типы используемые в языке, всегда изучаешь неявные преобразования, иначе невозможно. Например, мы знаем что int в php - это обычно int64, очевидно что возможно переполнение и нужно проверить как компилятор будет на него реагировать. В php реагировать он будет всегда одинаково - преобразует в float. И только потом, при записи в переменную может проверить ее тип.
Причем не обязательно знать все и вся, абсолютно неважно в какое конкретное значение string преобразовывается array (если такую хрень не использовать), но важно помнить, что получится строка, и без всяких ошибок.
Не говоря уже о том, что ошибки компиляции и runtime это совсем разные вещи в плане отладки.

Почему PHP считает int числа после математических операций как float?

Дмитрий, извиняюсь, неправильно прочитал, почемуто подумал, что там деление 2х int-ов. А для float - да, проще каст.

Почему PHP считает int числа после математических операций как float?

Дмитрий, очевидно имелось ввиду intdiv

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

Ziptar, ок, спасибо. Т.е. каких то повсеместных отказов бп нет, просто если неповезло, то на замену весь пк. Впрочем, я думаю, никто и не ждет, что в них все можно легко поменять также как в полноразмерных.

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

Ziptar, ну там много что не съемное, не заменяемое. И это логично. Но, с бп какаято проблема? Именно они выходят из строя чаще всего? Внутренние 12 вольтовые?

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

Ziptar, так там же внешний бп.

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

AlexVWill, djton1k, не заметил такого. Откуда такая информация?

Как запретить системе Ubuntu 24 убивать процесс systemd?

Мне нужно чтобы процесс systemd не прибивала ни при каких условиях

А она это делала?

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

Не нужно вообще ничего покупать. Разверните на виртуалке или в контейнере на домашнем компьютере. И только тогда, когда это заработает и будете этим пользоваться, и нсли понадобится, вот тогда и вернетесь к вопросу (а к тому времени и другие вопросы могут стать понятнее)

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

А что не так с минипс в работе 24/7?

Как системному администратору свичнуться в Devops-инженеры?

Alexey Dmitriev,

почти всем. Из "системного администратора" может пригодиться только работа с СУБД и Linux, ну и наверно ansible\terraform.

а конкретнее, вот тут выложили roadmap для devops-инженера, что там не относится к системному администрированию? по мне, так чисто инструменты сисадмина.

А так в российских реалиях девопсы - это поддержка команд разработки, а значит kubernetes, docker, конвейеры сборок и развертываний и все, что вокруг. Во главе угла не стабильность , а изменения на высокой скорости. Если системного администратора можно описать одним словом, то "инфраструктура", а если девопса - то наверно "развертывание (deploy)".

В российских реалиях вчерашние сисадмины теперь всюду и везде называются devops-инженеры, и не я это придумал. Даже если проект это не доставка программных фич, а разработка технического "железного" решения, все равно devops-инженер, потому что "модно и молодежно".
Не, я допускаю что может быть узкая специализация у сисадмина, например сетевики, но здесь... "Уверенный пользователь Gitlab и docker"? "конфигуратор Кубера"? Кубер для многих новый неизведанный инструмент, но сложные отказоустойчивые системы без Кубера конфигурировать не легче. А настроить CI/CD и контейнеризацию могут хоть разрабы, и не попросят их называть devops-инженерами.
Да, devops - это скорость, это мероприятия на быструю доставку новых фич. Методология учит, что этого можно достигнуть устранив бюрократические и технические паузы во флоу разработки, тестирования и эксплуатации. Сисадмины, или если хотите devops-инженеры, здесь помогают все той же инфраструктурой, автоматизацией работы этой инфраструктуры. CI/CD это не исключительное новое направление, а просто полная автоматизация. Да и kubernetes, и даже docker совсем не обязательны ни для CI/CD, ни для devops в целом. В общем все тоже самое, просто посыл "автоматизируйте наконец-то".
А стабильность здесь вообще не при чем, следуя devops методологии совсем не обязательно уничтожать стабильность, а если делать нормально, то она только расти будет.

Как раздать домашний интернет на мобильное устройство и пользоваться им отойдя от дома далеко?

hint000, возможно не по мощности, не скажу точно, но знаю, что когда приезжали с пеленгатором, нанки отрубали.