Ибо это уже совсем оксюморон.

Там их несколько, тащемто.

При чём тут API?

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

А можете привести пример как бы вы его написали читабельнее, используя нормальные практики программирования ?

Агонь, не знал :-(

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

А смысл так делать, дальше же будет очный этап.

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

Не нагнетайте, в PHP5 это работает даже быстрее, чем strlen($str), а в PHP7 вообще без разницы.

Мы в Баду, кстати, тоже так делаем. Это, правда, не отменяет того факта что после простых задач мы обычно спрашиваем задачи на посложнее, в обсуждении которых можно подчас сильно отойти от темы и даже если кандидат её уже решал, обсуждал или видел решение в интернете, это не гарантирует 100% успех.

Те, кто его круто прошёл, уже были на наших интервью. Но сам тест никто особо не пиарит, потому потока кандидатов с него нет и, как мне кажется, никогда и не было.

Переходите на современные версии PHP, у нас есть плюшки!

Всё верно, а такое поведение связано с тем, что echo кастует все параметры к string следующим образом:

case IS_DOUBLE: {
    zend_string *str;
    double dval = Z_DVAL_P(op);

    str = zend_strpprintf(0, "%.*G", (int) EG(precision), dval);
    /* %G already handles removing trailing zeros from the fractional part, yay */
    ZVAL_NEW_STR(op, str);
    break;
}

Спасибо, вы правы, поправил текст.

Именно так.

Интересно, поглядим.

Мы, кстати, именно эту сборку и используем.

crocodile2u, мы не запускаем MySQL в Docker, придерживаемся пока что старой практике по одному MySQL сервису на сервер. Единственно, что контейнеризировано — это pinba, но там нет необходимости хранить данные.

С HandlerSocket ситуация сейчас довольно интересная: в MySQL 5.7 он не поддерживается, ванильный Memcache Protocol не поддерживает всего что умел HandlerSocket (например multi-get), а на подходе уже возможность использовать с клиентов X Protocol. Так что пока что держим HandlerSocket на MySQL 5.6.

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

А что может быть проще каталога с файлами для загрузки в качестве очереди — с трудом представляю.

Это могло бы быть так, если бы это была планет Маленького Принца в Сферическом Вакууме. Уверен что у любого проекта где используются очереди есть удобный фремворк для работы с ними (и они лежат в базах данных, не обязателно SQL-ных), и писать реализацию очередей на файлах для отдельной подсистемы выглядит просто как трата времени.

Думаю, мы по-разному себе представляем реализации.

А как вы будете на файлах реализовывать, допустим, откладывание событий?

В дополнение к Антону отвечу почему PHP код мы не выкладываем контейнерами. Причины довольно простые: мы хотим выкладываться часто (сейчас это 2 раза в день на продакшен и, по статистике, каждые минут 10 на стейджинг), при этом PHP приложение представляет из себя монолит, один код которого занимает ~200Mb, завендорено ещё столько же (можно уменьшить елси почистить тесты и много чего ещё в них). При раскладке на продакшен всё это нужно доставить на сотни серверов, потому нам приходится постоянно изменять собственную систему деплоя. Более подробно об этом можно посмотреть в докладе Юры youROCK Насретдинова на Youtube.